[jira] [Updated] (CSV-90) CSVFormat isEscaping/isEncapsulating are not public
[ https://issues.apache.org/jira/browse/CSV-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated CSV-90: Summary: CSVFormat isEscaping/isEncapsulating are not public (was: CSVFormat isEscaping/isEscaping are not public) CSVFormat isEscaping/isEncapsulating are not public --- Key: CSV-90 URL: https://issues.apache.org/jira/browse/CSV-90 Project: Commons CSV Issue Type: Bug Reporter: Sebb The CSVFormat methods isEscaping() and isEncapsulating() are package protected, whereas the other 3 isXXX() methods are public. There seems no reason for this difference. These are external settings - they are defined by the user - so I don't see why the methods should not be public. AFAICT making them public would not commit the API to anything new. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CODEC-96) Base64 encode() method is no longer thread-safe, breaking clients using it as a shared BinaryEncoder
[
https://issues.apache.org/jira/browse/CODEC-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb updated CODEC-96:
--
Attachment: CODEX-96-2.patch
Supersedes CODEX-96.patch
Base64 encode() method is no longer thread-safe, breaking clients using it as
a shared BinaryEncoder
Key: CODEC-96
URL: https://issues.apache.org/jira/browse/CODEC-96
Project: Commons Codec
Issue Type: Bug
Affects Versions: 1.4
Reporter: Matt Ryall
Assignee: Julius Davies
Fix For: 1.x
Attachments: CODEC-96.patch, CODEX-96-2.patch,
codec-96-3rd-attempt.patch
Streaming support was added to Base64 in commons-codec 1.4 with CODEC-69.
This introduced instance variables to Base64 which means the class can no
longer be used as a shared BinaryEncoder instance.
For example, BinaryEncoder has an interface which could be (and was) used
like this with Base64:
{code:java}
class Example {
private BinaryEncoder encoder = new Base64();
byte[] someMethod(byte[] data) {
try {
return encoder.encode(data);
}
catch (EncoderException e) {
throw new RuntimeException(e);
}
}
}
{code}
Base64 is no longer thread-safe in commons-codec 1.4, so code like the above
which is accessed by multiple threads can throw NullPointerException:
{noformat}
java.lang.NullPointerException
at org.apache.commons.codec.binary.Base64.encode(Base64.java:469)
at org.apache.commons.codec.binary.Base64.encode(Base64.java:937)
at ... (application code)
{noformat}
Looking at the implementation of Base64, I think making it thread-safe for
this kind of usage would be quite tricky. I haven't attempted to prepare a
patch.
I would be happy if it was indicated in the Javadoc that Base64 is not
thread-safe and should not be shared. However, some other users of
commons-codec might be more worried about this regression.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CSV-70) Improve readability of CSVLexer
[ https://issues.apache.org/jira/browse/CSV-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated CSV-70: Description: There are several things that can be improved in the token lexer (this has also been discussed on ML, see http://markmail.org/thread/c6x5ji4v44nx5k4h): * Remove Token input parameter in nextToken() (x) this makes lexer slower * Add convenience methods isDelimiter(c) and isEncapsulator(c) (/) * Remove current caracter input parameter from methods (/) * If possible: replace while(true) loops was: There are several things that can be improved in the token lexer (this has also been discussed on ML, see http://markmail.org/thread/c6x5ji4v44nx5k4h): * Remove Token input parameter in nextToken() * Add convenience methods isDelimiter(c) and isEncapsulator(c) * Remove current caracter input parameter from methods * If possible: replace while(true) loops Improve readability of CSVLexer --- Key: CSV-70 URL: https://issues.apache.org/jira/browse/CSV-70 Project: Commons CSV Issue Type: Improvement Components: Parser Affects Versions: 1.0 Reporter: Benedikt Ritter Fix For: 1.0 There are several things that can be improved in the token lexer (this has also been discussed on ML, see http://markmail.org/thread/c6x5ji4v44nx5k4h): * Remove Token input parameter in nextToken() (x) this makes lexer slower * Add convenience methods isDelimiter(c) and isEncapsulator(c) (/) * Remove current caracter input parameter from methods (/) * If possible: replace while(true) loops -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CSV-58) Eascape handling needs rethinking
[ https://issues.apache.org/jira/browse/CSV-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated CSV-58: Summary: Eascape handling needs rethinking (was: Unicode escapes are lost if escape character is backslash) Eascape handling needs rethinking - Key: CSV-58 URL: https://issues.apache.org/jira/browse/CSV-58 Project: Commons CSV Issue Type: Bug Components: Parser Reporter: Sebb Fix For: 1.0 The current escape parsing converts escchar to plain char if the char is not one of the special characters to be escaped. This can affect unicode escapes if the esc character is backslash. One way round this is to specifically check for char == 'u', but it seems wrong to only do this for 'u'. Another solution would be to leave escchar as is unless the char is one of the special characters. There are several possible ways to treat unrecognised escapes: - treat it as if the escape char had not been present (current behaviour) - leave the escape char as is - throw an exception -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CSV-58) Escape handling needs rethinking
[ https://issues.apache.org/jira/browse/CSV-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated CSV-58: Summary: Escape handling needs rethinking (was: Eascape handling needs rethinking) Escape handling needs rethinking Key: CSV-58 URL: https://issues.apache.org/jira/browse/CSV-58 Project: Commons CSV Issue Type: Bug Components: Parser Reporter: Sebb Fix For: 1.0 The current escape parsing converts escchar to plain char if the char is not one of the special characters to be escaped. This can affect unicode escapes if the esc character is backslash. One way round this is to specifically check for char == 'u', but it seems wrong to only do this for 'u'. Another solution would be to leave escchar as is unless the char is one of the special characters. There are several possible ways to treat unrecognised escapes: - treat it as if the escape char had not been present (current behaviour) - leave the escape char as is - throw an exception -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-255) XML handler to serialize/de-serialize FileEntry instances to/from XML
[ https://issues.apache.org/jira/browse/IO-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated IO-255: Summary: XML handler to serialize/de-serialize FileEntry instances to/from XML (was: XML handler to serialize/de-serialize FlieEntrys to/from XML) XML handler to serialize/de-serialize FileEntry instances to/from XML - Key: IO-255 URL: https://issues.apache.org/jira/browse/IO-255 Project: Commons IO Issue Type: New Feature Affects Versions: 2.0 Reporter: Niall Pemberton Assignee: Niall Pemberton Priority: Minor Attachments: FileEntryXmlHandler.java It may be usefule to *capture* the state of a Filesystem and serialize it. I've been playing with a handler that can serialize/de-serialize a FileEntry and its children to/from XML. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CSV-73) HSQLDB supports two different field separators
[ https://issues.apache.org/jira/browse/CSV-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated CSV-73: Description: HSQLDB supports a second field separator for VARCHAR fields according to: http://www.hsqldb.org/doc/2.0/guide/texttables-chapt.html#ttc_configuration Do we want to implement this? was: HSQLDB supports a second field separator for VARCHAR fields according to: http://www.hsqldb.org/doc/2.0/guide/texttables-chapt.html#ttc_configuration Do we want to implrment this? HSQLDB supports two different field separators -- Key: CSV-73 URL: https://issues.apache.org/jira/browse/CSV-73 Project: Commons CSV Issue Type: New Feature Reporter: Sebb HSQLDB supports a second field separator for VARCHAR fields according to: http://www.hsqldb.org/doc/2.0/guide/texttables-chapt.html#ttc_configuration Do we want to implement this? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (NET-455) FTPClient listFiles(FTPFileFilter) can be faster...
[
https://issues.apache.org/jira/browse/NET-455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb updated NET-455:
-
Description:
I tested two ways of sorting files on a remote FTP server with many files (
110 000). Both of these use the FtpFileFilter class (with a test on the
extension filename... very simple).
The first one is the conventionnal =
{code}
files = ftpClient.listFiles(./, ftpFileFilter);
{code}
It takes about 90 seconds ...
the second one is ... nearly as simple as the first one :
{code}
FTPFile [] allFilesListed = ftpClient.listFiles();
files = FTPFileFilterWithExtension.fastFilter(ftpFileFilter, allFilesListed);
{code}
The function FTPFileFilterWithExtension.fastFilter() call the same
ftpFileFilter :
{code}
public static FTPFile [] fastFilter(FTPFileFilter filter, FTPFile ftpFileArray
[]) {
ArrayListFTPFile listOfFTPFiles = new ArrayListFTPFile();
for (FTPFile ftpf : ftpFileArray) {
boolean accepted = filter.accept(ftpf);
if (accepted) {
listOfFTPFiles.add(ftpf);
}
}
FTPFile resultArray [] = new FTPFile[listOfFTPFiles.size()];
return listOfFTPFiles.toArray(resultArray);
}
{code}
The second method is EIGHT times faster than the first one ... and I don't
really understand why...
was:
I tested two ways of sorting files on a remote FTP server with many files (
110 000). Both of these use the FtpFileFilter class (with a test on the
extension filename... very simple).
The first one is the conventionnal = files = ftpClient.listFiles(./,
ftpFileFilter);
It takes about 90 seconds ...
the second one is ... nearly as simple as the first one :
FTPFile [] allFilesListed = ftpClient.listFiles();
files = FTPFileFilterWithExtension.fastFilter(ftpFileFilter, allFilesListed);
The function FTPFileFilterWithExtension.fastFilter() call the same
ftpFileFilter :
public static FTPFile [] fastFilter(FTPFileFilter filter, FTPFile
ftpFileArray []) {
ArrayListFTPFile listOfFTPFiles = new ArrayListFTPFile();
for (FTPFile ftpf : ftpFileArray) {
boolean accepted = filter.accept(ftpf);
if (accepted) {
listOfFTPFiles.add(ftpf);
}
}
FTPFile resultArray [] = new FTPFile[listOfFTPFiles.size()];
return listOfFTPFiles.toArray(resultArray);
}
The second method is EIGHT times faster than the first one ... and I don't
really understand why...
FTPClient listFiles(FTPFileFilter) can be faster...
---
Key: NET-455
URL: https://issues.apache.org/jira/browse/NET-455
Project: Commons Net
Issue Type: Improvement
Components: FTP
Affects Versions: 3.0.1
Environment: all
Reporter: Nicolas
Priority: Minor
Labels: ftpclient, listFiles
Original Estimate: 1h
Remaining Estimate: 1h
I tested two ways of sorting files on a remote FTP server with many files (
110 000). Both of these use the FtpFileFilter class (with a test on the
extension filename... very simple).
The first one is the conventionnal =
{code}
files = ftpClient.listFiles(./, ftpFileFilter);
{code}
It takes about 90 seconds ...
the second one is ... nearly as simple as the first one :
{code}
FTPFile [] allFilesListed = ftpClient.listFiles();
files = FTPFileFilterWithExtension.fastFilter(ftpFileFilter, allFilesListed);
{code}
The function FTPFileFilterWithExtension.fastFilter() call the same
ftpFileFilter :
{code}
public static FTPFile [] fastFilter(FTPFileFilter filter, FTPFile
ftpFileArray []) {
ArrayListFTPFile listOfFTPFiles = new ArrayListFTPFile();
for (FTPFile ftpf : ftpFileArray) {
boolean accepted = filter.accept(ftpf);
if (accepted) {
listOfFTPFiles.add(ftpf);
}
}
FTPFile resultArray [] = new FTPFile[listOfFTPFiles.size()];
return listOfFTPFiles.toArray(resultArray);
}
{code}
The second method is EIGHT times faster than the first one ... and I don't
really understand why...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (NET-450) Bug in documentation for FTPClient
[ https://issues.apache.org/jira/browse/NET-450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated NET-450: - Description: In the Documentation for FTPClient there are some examples One is FTPClient f = new FTPClient(); f.connect(server); f.login(username, password); FTPFile[] files = listFiles(directory); There is a typo on the last line. It should be f.listFiles(directory); Rating this as Minior as any decent Java programmer should work it out. was: In the Documentation for FTPClass there are some examples One is FTPClient f = new FTPClient(); f.connect(server); f.login(username, password); FTPFile[] files = listFiles(directory); There is a typo on the last line. It should be f.listFiles(directory); Rating this as Minior as any decent Java programmer should work it out. Summary: Bug in documentation for FTPClient (was: Bug in documentation for FTPClass) Bug in documentation for FTPClient -- Key: NET-450 URL: https://issues.apache.org/jira/browse/NET-450 Project: Commons Net Issue Type: Bug Components: FTP Affects Versions: 3.1 Environment: Documentation on Apache web site Reporter: Roger Hardiman Priority: Minor Original Estimate: 5m Remaining Estimate: 5m In the Documentation for FTPClient there are some examples One is FTPClient f = new FTPClient(); f.connect(server); f.login(username, password); FTPFile[] files = listFiles(directory); There is a typo on the last line. It should be f.listFiles(directory); Rating this as Minior as any decent Java programmer should work it out. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CSV-79) CSVFormat.isCommentingDisabled() is confusing/confused
[
https://issues.apache.org/jira/browse/CSV-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb updated CSV-79:
Summary: CSVFormat.isCommentingDisabled() is confusing/confused (was:
CSVFormat.isCommentingDisabled() is very confused)
CSVFormat.isCommentingDisabled() is confusing/confused
--
Key: CSV-79
URL: https://issues.apache.org/jira/browse/CSV-79
Project: Commons CSV
Issue Type: Bug
Reporter: Sebb
The Javadoc for CSVFormat.isCommentingDisabled() says:
{code}
/**
* Specifies whether comments are supported by this format.
*
* @return tttrue/tt is comments are supported, ttfalse/tt otherwise
*/
{code}
however the method actually does the opposite, as the name suggests.
Now we could just fix the Javadoc, but given that the other isXXX methods
return a positive result this would be inconsistent.
Also, it's generally better to return positive setting.
So I think renaming the method as isCommentingEnabled - and fixing the
method code - would be better.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CODEC-96) Base64 encode() method is no longer thread-safe, breaking clients using it as a shared BinaryEncoder
[
https://issues.apache.org/jira/browse/CODEC-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb updated CODEC-96:
--
Attachment: CODEC-96.patch
Base64 encode() method is no longer thread-safe, breaking clients using it as
a shared BinaryEncoder
Key: CODEC-96
URL: https://issues.apache.org/jira/browse/CODEC-96
Project: Commons Codec
Issue Type: Bug
Affects Versions: 1.4
Reporter: Matt Ryall
Assignee: Julius Davies
Fix For: 1.x
Attachments: CODEC-96.patch, codec-96-3rd-attempt.patch
Streaming support was added to Base64 in commons-codec 1.4 with CODEC-69.
This introduced instance variables to Base64 which means the class can no
longer be used as a shared BinaryEncoder instance.
For example, BinaryEncoder has an interface which could be (and was) used
like this with Base64:
{code:java}
class Example {
private BinaryEncoder encoder = new Base64();
byte[] someMethod(byte[] data) {
try {
return encoder.encode(data);
}
catch (EncoderException e) {
throw new RuntimeException(e);
}
}
}
{code}
Base64 is no longer thread-safe in commons-codec 1.4, so code like the above
which is accessed by multiple threads can throw NullPointerException:
{noformat}
java.lang.NullPointerException
at org.apache.commons.codec.binary.Base64.encode(Base64.java:469)
at org.apache.commons.codec.binary.Base64.encode(Base64.java:937)
at ... (application code)
{noformat}
Looking at the implementation of Base64, I think making it thread-safe for
this kind of usage would be quite tricky. I haven't attempted to prepare a
patch.
I would be happy if it was indicated in the Javadoc that Base64 is not
thread-safe and should not be shared. However, some other users of
commons-codec might be more worried about this regression.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-309) UnicodeUnescapeReader?
[ https://issues.apache.org/jira/browse/IO-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated IO-309: Attachment: UnicodeUnescapeReader.java UnicodeUnescapeReader? -- Key: IO-309 URL: https://issues.apache.org/jira/browse/IO-309 Project: Commons IO Issue Type: New Feature Reporter: Sebb Priority: Minor Attachments: UnicodeUnescapeReader.java The CSV project developed a UnicodeUnescapeReader, but it is no longer needed there. Perhaps it would be useful in IO? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CSV-74) CSVFormat definitions are difficult to read and maintain
[ https://issues.apache.org/jira/browse/CSV-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated CSV-74: Attachment: CSV-74.patch CSVFormat definitions are difficult to read and maintain Key: CSV-74 URL: https://issues.apache.org/jira/browse/CSV-74 Project: Commons CSV Issue Type: Improvement Reporter: Sebb Attachments: CSV-74.patch The CSVFormat definitions (DEFAULT, EXCEL etc) are very difficult to read because the ctor has so many parameters. Also, any change to the ctor parameters means all the definitions have to be changed. It would be much easier if the constants were defined using the standard API. This can be done by defining a base format (with everything disabled or null) and generating the constants from that. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CONFIGURATION-486) BeanHelper.setDefaultBeanFactory() is thread-hostile and not thread-safe
[ https://issues.apache.org/jira/browse/CONFIGURATION-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated CONFIGURATION-486: --- Comment: was deleted (was: A few more examples) BeanHelper.setDefaultBeanFactory() is thread-hostile and not thread-safe Key: CONFIGURATION-486 URL: https://issues.apache.org/jira/browse/CONFIGURATION-486 Project: Commons Configuration Issue Type: Bug Reporter: Sebb BeanHelper.setDefaultBeanFactory() sets a private static field. This is thread-hostile, because different threads cannot safely use different factories. It's also not thread-safe, as the variable is not guaranteed to be published safely. Should either make the variable volatile, or synchronize both getter and setter. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CSV-75) ExtendedBufferReader does not handle EOL consistently
[ https://issues.apache.org/jira/browse/CSV-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated CSV-75: Attachment: CSV-75.patch ExtendedBufferReader does not handle EOL consistently - Key: CSV-75 URL: https://issues.apache.org/jira/browse/CSV-75 Project: Commons CSV Issue Type: Bug Reporter: Sebb Attachments: CSV-75.patch ExtendedBufferReader checks for '\n' (LF) in the read() methods, incrementing linecount when found. However, the readLine() method calls BufferedReader.readLine() which treats CR, LF and CRLF equally (and drops them). If the code is to be flexible in what it accepts, the class should also allow for CR alone as a line terminator. It should work if the code increments the line counter for CR, and for LF if the previous character was not CR. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CONFIGURATION-485) Class fields set by ctors should be final if they don't need to be changed later
[ https://issues.apache.org/jira/browse/CONFIGURATION-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated CONFIGURATION-485: --- Attachment: CONFIGURATION-485-3.patch Another batch of private finals Class fields set by ctors should be final if they don't need to be changed later Key: CONFIGURATION-485 URL: https://issues.apache.org/jira/browse/CONFIGURATION-485 Project: Commons Configuration Issue Type: Improvement Reporter: Sebb Attachments: CONFIGURATION-485-2.patch, CONFIGURATION-485-3.patch, CONFIGURATION-485.patch Using final whereever possible simplifies testing (fewer possible states) and improves thread-safety (final fields may not need synch.) Obviously changing public or protected fields to final may cause problems for binary compatibility (if they form part of the public API), but for private/package variables that is not a concern. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CSV-68) Use Builder pattern for CSVFormat
[
https://issues.apache.org/jira/browse/CSV-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb updated CSV-68:
Attachment: CSV-68.patch
Patch with skeleton implementation
Use Builder pattern for CSVFormat
-
Key: CSV-68
URL: https://issues.apache.org/jira/browse/CSV-68
Project: Commons CSV
Issue Type: Improvement
Reporter: Sebb
Attachments: CSV-68.patch
Using a builder pattern to create CSVFormat instances would allow the
settings to be validated at creation time and would eliminate the need to
keep creating new CSVFormat instances whilst still allowing the class to be
immutable.
A possible API is as follows:
{code}
CSVFormat DEFAULT = CSVFormat.init(',') // delimiter is required
.withEncapsulator('')
.withLeadingSpacesIgnored(true)
.withTrailingSpacesIgnored(true)
.withEmptyLinesIgnored(true)
.withLineSeparator(\r\n) // optional, as it would be the default
.build();
CSVFormat format = CSVFormat.init(CSVFormat.DEFAULT) // alternatively start
with pre-defined format
.withSurroundingSpacesIgnored(false)
.build();
{code}
Compare this with the current syntax:
{code}
// internal syntax; not easy to determine what all the parameters do
CSVFormat DEFAULT1 = new CSVFormat(',', '', DISABLED, DISABLED, true, true,
false, true, CRLF);
// external syntax
CSVFormat format = CSVFormat.DEFAULT.withSurroundingSpacesIgnored(false);
{code}
As a proof of concept I've written skeleton code which compiles (but needs
completing).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CONFIGURATION-485) Class fields set by ctors should be final if they don't need to be changed later
[ https://issues.apache.org/jira/browse/CONFIGURATION-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated CONFIGURATION-485: --- Attachment: CONFIGURATION-485.patch Sample patch for ConfigurationMap. Similar fixes could be applied to other classes. Class fields set by ctors should be final if they don't need to be changed later Key: CONFIGURATION-485 URL: https://issues.apache.org/jira/browse/CONFIGURATION-485 Project: Commons Configuration Issue Type: Improvement Reporter: Sebb Attachments: CONFIGURATION-485.patch Using final whereever possible simplifies testing (fewer possible states) and improves thread-safety (final fields may not need synch.) Obviously changing public or protected fields to final may cause problems for binary compatibility (if they form part of the public API), but for private/package variables that is not a concern. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CONFIGURATION-486) BeanHelper.setDefaultBeanFactory() is thread-hostile and not thread-safe
[ https://issues.apache.org/jira/browse/CONFIGURATION-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated CONFIGURATION-486: --- Attachment: CONFIGURATION-485-2.patch A few more examples BeanHelper.setDefaultBeanFactory() is thread-hostile and not thread-safe Key: CONFIGURATION-486 URL: https://issues.apache.org/jira/browse/CONFIGURATION-486 Project: Commons Configuration Issue Type: Bug Reporter: Sebb BeanHelper.setDefaultBeanFactory() sets a private static field. This is thread-hostile, because different threads cannot safely use different factories. It's also not thread-safe, as the variable is not guaranteed to be published safely. Should either make the variable volatile, or synchronize both getter and setter. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CONFIGURATION-486) BeanHelper.setDefaultBeanFactory() is thread-hostile and not thread-safe
[ https://issues.apache.org/jira/browse/CONFIGURATION-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated CONFIGURATION-486: --- Attachment: (was: CONFIGURATION-485-2.patch) BeanHelper.setDefaultBeanFactory() is thread-hostile and not thread-safe Key: CONFIGURATION-486 URL: https://issues.apache.org/jira/browse/CONFIGURATION-486 Project: Commons Configuration Issue Type: Bug Reporter: Sebb BeanHelper.setDefaultBeanFactory() sets a private static field. This is thread-hostile, because different threads cannot safely use different factories. It's also not thread-safe, as the variable is not guaranteed to be published safely. Should either make the variable volatile, or synchronize both getter and setter. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CONFIGURATION-485) Class fields set by ctors should be final if they don't need to be changed later
[ https://issues.apache.org/jira/browse/CONFIGURATION-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated CONFIGURATION-485: --- Attachment: CONFIGURATION-485-2.patch A few more examples Class fields set by ctors should be final if they don't need to be changed later Key: CONFIGURATION-485 URL: https://issues.apache.org/jira/browse/CONFIGURATION-485 Project: Commons Configuration Issue Type: Improvement Reporter: Sebb Attachments: CONFIGURATION-485-2.patch, CONFIGURATION-485.patch Using final whereever possible simplifies testing (fewer possible states) and improves thread-safety (final fields may not need synch.) Obviously changing public or protected fields to final may cause problems for binary compatibility (if they form part of the public API), but for private/package variables that is not a concern. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-307) ReaderInputStream#read(byte[] b, int off, int len) should check for valid parameters
[ https://issues.apache.org/jira/browse/IO-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated IO-307: Affects Version/s: 2.1 ReaderInputStream#read(byte[] b, int off, int len) should check for valid parameters Key: IO-307 URL: https://issues.apache.org/jira/browse/IO-307 Project: Commons IO Issue Type: Bug Affects Versions: 2.1 Reporter: Sebb If the buffer is null, the method should throw NPE immediately (rather than letting it occur later) If the offset or length are 0 or would overflow the buffer, then throw IndexOutOfBoundsException with details of the values. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-306) ReaderInputStream#read(byte[] b, int off, int len) should always return 0 for length == 0
[ https://issues.apache.org/jira/browse/IO-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated IO-306: Affects Version/s: 2.1 Fix Version/s: 2.2 ReaderInputStream#read(byte[] b, int off, int len) should always return 0 for length == 0 - Key: IO-306 URL: https://issues.apache.org/jira/browse/IO-306 Project: Commons IO Issue Type: Bug Affects Versions: 2.1 Reporter: Sebb Fix For: 2.2 The method read(byte[] b, int off, int len) should always return 0 if the requested length == 0, even if the stream is empty or at EOF, as that is how the overridden java.io.InputStream method is documented to behave. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-213) LineIterator should implement IteratorString as well/instead of Iterator
[ https://issues.apache.org/jira/browse/IO-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated IO-213: Fix Version/s: 2.0 LineIterator should implement IteratorString as well/instead of Iterator --- Key: IO-213 URL: https://issues.apache.org/jira/browse/IO-213 Project: Commons IO Issue Type: Bug Components: Utilities Reporter: Robert Collins Priority: Trivial Fix For: 2.0 Typesafety is nicer than having to cast from object on every pass through the loop. As LineIterator only outputs strings, this should be trivial. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-223) IOUtils.copy Javadoc inconsistency (return -1 vs. throw ArithmeticException)
[ https://issues.apache.org/jira/browse/IO-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated IO-223: Fix Version/s: 2.0 IOUtils.copy Javadoc inconsistency (return -1 vs. throw ArithmeticException) Key: IO-223 URL: https://issues.apache.org/jira/browse/IO-223 Project: Commons IO Issue Type: Bug Components: Utilities Affects Versions: 1.3, 1.3.1, 1.3.2, 1.4 Reporter: Adam Michalik Fix For: 2.0 The javadoc for IOUtils.copy says: Large streams (over 2GB) will return a bytes copied value of -1 after the copy has completed since the correct number of bytes cannot be returned as an int. but then it says: Throws: ArithmeticException - if the byte count is too large This is an inconsistency since -1 is always returned if the byte count is too large. ArithmeticException is never actually thrown. See IO-84 for discussion on solving the too large byte count problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-207) Race condition in forceMkdir
[ https://issues.apache.org/jira/browse/IO-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated IO-207: Fix Version/s: 2.0 Race condition in forceMkdir Key: IO-207 URL: https://issues.apache.org/jira/browse/IO-207 Project: Commons IO Issue Type: Bug Components: Utilities Affects Versions: 1.4 Environment: Windows Reporter: Luke Quinane Priority: Minor Fix For: 2.0 Attachments: forceMkdir.patch Original Estimate: 1h Remaining Estimate: 1h If two processes or threads call forceMkdir() with the same directory there is a chance that one will throw an IOException even though a directory was correctly created (by the other process or thread). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-187) FileSystemUtils.freeSpaceKb doesn't work with relative paths on Linux
[ https://issues.apache.org/jira/browse/IO-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated IO-187: Fix Version/s: 2.0 FileSystemUtils.freeSpaceKb doesn't work with relative paths on Linux - Key: IO-187 URL: https://issues.apache.org/jira/browse/IO-187 Project: Commons IO Issue Type: Bug Components: Utilities Affects Versions: 1.2, 1.3, 1.3.1, 1.3.2, 1.4 Environment: Linux Reporter: Cormac Blackwell Fix For: 2.0 Calling FileSystemUtils.freeSpaceKb with ., ./, ../, ../foo etc. will result in an empty string being passed to df. freeSpaceKb calls FileNameUtils.normalize on the path which destroys relative paths. I don't see any need to normalize the path so the fix is simply to remove that call. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-205) FileUtils.forceMkdir Javadoc is unclear
[ https://issues.apache.org/jira/browse/IO-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated IO-205: Component/s: Utilities Fix Version/s: 2.0 FileUtils.forceMkdir Javadoc is unclear --- Key: IO-205 URL: https://issues.apache.org/jira/browse/IO-205 Project: Commons IO Issue Type: Bug Components: Utilities Reporter: Trejkaz Fix For: 2.0 The Javadoc for FileUtils.forceMkdir doesn't say what is supposed to happen if a directory already exists with the same path. It does (misleadingly) say that if a file already exists, it fails. I interpreted this to mean that a directory would also fail, as it said *file* and not *normal file*. However in reality, if the directory already exists, the method passes. For clarity it should say that it succeeds if the directory already exists, and should probably also explicitly say normal file instead of just file, as all directories are files. Also, internally, I notice it is checking for File.isFile() whereas our existing method for implementing the same thing is checking !File.isDirectory(). On some filesystems, a file can be both a directory and a normal file, and in this situation I would expect the method to pass, whereas with Commons' implementation it would fail. Maybe this is a trip-up because Sun themselves documented normal file as meaning something which is not a directory, which is going to break the moment someone runs something on a more exotic filesystem. :-( -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-191) Possible improvements using static analysis.
[ https://issues.apache.org/jira/browse/IO-191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated IO-191: Fix Version/s: 2.0 Possible improvements using static analysis. Key: IO-191 URL: https://issues.apache.org/jira/browse/IO-191 Project: Commons IO Issue Type: Improvement Reporter: Peter Lawrey Priority: Trivial Fix For: 2.0 Attachments: commons-io-static-analysis.patch Original Estimate: 3h Remaining Estimate: 3h -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-275) org.apache.commons.io.FileUtils.contentEquals - Add option to ignore line endings
[ https://issues.apache.org/jira/browse/IO-275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated IO-275: Fix Version/s: 2.2 org.apache.commons.io.FileUtils.contentEquals - Add option to ignore line endings --- Key: IO-275 URL: https://issues.apache.org/jira/browse/IO-275 Project: Commons IO Issue Type: New Feature Components: Utilities Reporter: CJ Aspromgos Fix For: 2.2 FileUtils has a nice member function to compare two files. It would be nice if the client had the option to ignore line endings. This way files (specifically text files) generated on different platforms (eg windows, unix) would match. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-124) fix website permissions
[ https://issues.apache.org/jira/browse/IO-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated IO-124: Fix Version/s: 1.3.2 fix website permissions --- Key: IO-124 URL: https://issues.apache.org/jira/browse/IO-124 Project: Commons IO Issue Type: Bug Reporter: Godmar Back Fix For: 1.3.2 http://jakarta.apache.org/commons/io/api-release/index.html says: Forbidden You don't have permission to access /commons/io/api-release/index.html on this server. Apache/2.3.0-dev (Unix) Server at jakarta.apache.org Port 80 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-291) Add new function FileUtils.directoryContains
[ https://issues.apache.org/jira/browse/IO-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated IO-291: Fix Version/s: (was: 2.2) Add new function FileUtils.directoryContains Key: IO-291 URL: https://issues.apache.org/jira/browse/IO-291 Project: Commons IO Issue Type: New Feature Components: Utilities Affects Versions: 2.1 Reporter: Pier-Luc Caron St-Pierre Assignee: Gary D. Gregory Labels: patch Attachments: io-291-simple.diff, io-291-v5.patch I added a function that determines whether the specified leaf is contains by the specified composite. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-300) FileUtils.moveDirectoryToDirectory removes source directory if destination is a subdirectory
[ https://issues.apache.org/jira/browse/IO-300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated IO-300: Summary: FileUtils.moveDirectoryToDirectory removes source directory if destination is a subdirectory (was: FileUtils.moveDirectoryToDirectory removing source directory) FileUtils.moveDirectoryToDirectory removes source directory if destination is a subdirectory Key: IO-300 URL: https://issues.apache.org/jira/browse/IO-300 Project: Commons IO Issue Type: Bug Reporter: dennis lucero Attachments: IO-300.patch Since moveDirectoryToDirectory performs a copy then delete, if you specify a target directory that is a subdirectory of the source, everything under the source directory is deleted. Steps to recreate: File dest = new File(/tmp/dir1/dir2); File src = new File(/tmp/dir1/); dest.mkdirs(); System.out.println(src.exists()); FileUtils.moveDirectoryToDirectory(src, dest, false); System.out.println(src.exists()); Output: true false If you try the same thing with a move command on Linux, you receive: mv: cannot move `dir1/' to a subdirectory of itself, `dir1/dir2/dir1' Maybe throw an exception if dest.getCanonicalPath().startsWith(src.getCanonicalPath()) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SANDBOX-408) CSVFormat describes itself as immutable, but it is not - in particular it is not thread-safe
[ https://issues.apache.org/jira/browse/SANDBOX-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated SANDBOX-408: - Attachment: CSVFormat.java CSVFormat.java reworked to use all final variables. [Can be provided as diff if required; it's easier to understand a full source file] CSVFormat describes itself as immutable, but it is not - in particular it is not thread-safe Key: SANDBOX-408 URL: https://issues.apache.org/jira/browse/SANDBOX-408 Project: Commons Sandbox Issue Type: Bug Components: CSV Reporter: Sebb Attachments: CSVFormat.java CSVFormat describes itself as immutable, but it is not @Immutable - the class fields are all mutable. The methods that change the fields do so by creating a clone, and returning the changed clone. So in a sense the class is immutable. However, the normal expectation is that @Immutable classes are @ThreadSafe. CSVFormat is not thread-safe, because the fields are not volatile, and the fields are not written read using a common lock. The comment needs to be clarified or removed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COLLECTIONS-398) BoundedFifoBuffer could be simplified by keeping a count of the number of entries
[ https://issues.apache.org/jira/browse/COLLECTIONS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated COLLECTIONS-398: - Attachment: COLLECTIONS-398.patch Patch to replace full boolean with numEntries int. BoundedFifoBuffer could be simplified by keeping a count of the number of entries - Key: COLLECTIONS-398 URL: https://issues.apache.org/jira/browse/COLLECTIONS-398 Project: Commons Collections Issue Type: Improvement Reporter: Sebb Attachments: COLLECTIONS-398.patch BoundedFifoBuffer could be much simplified by keeping a count of the number of entries, and dropping the boolean full. This would speed up size() and isEmpty() and isFull(). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COLLECTIONS-398) BoundedFifoBuffer could be simplified by keeping a count of the number of entries
[ https://issues.apache.org/jira/browse/COLLECTIONS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated COLLECTIONS-398: - Attachment: COLLECTIONS-398-2.patch Better patch - no need to check for null element in remove() BoundedFifoBuffer could be simplified by keeping a count of the number of entries - Key: COLLECTIONS-398 URL: https://issues.apache.org/jira/browse/COLLECTIONS-398 Project: Commons Collections Issue Type: Improvement Reporter: Sebb Attachments: COLLECTIONS-398-2.patch, COLLECTIONS-398.patch BoundedFifoBuffer could be much simplified by keeping a count of the number of entries, and dropping the boolean full. This would speed up size() and isEmpty() and isFull(). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SANDBOX-408) CSVFormat describes itself as immutable, but it is not - in particular it is not thread-safe
[ https://issues.apache.org/jira/browse/SANDBOX-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated SANDBOX-408: - Attachment: (was: COLLECTIONS-398-2.patch) CSVFormat describes itself as immutable, but it is not - in particular it is not thread-safe Key: SANDBOX-408 URL: https://issues.apache.org/jira/browse/SANDBOX-408 Project: Commons Sandbox Issue Type: Bug Components: CSV Reporter: Sebb Attachments: CSVFormat.java CSVFormat describes itself as immutable, but it is not @Immutable - the class fields are all mutable. The methods that change the fields do so by creating a clone, and returning the changed clone. So in a sense the class is immutable. However, the normal expectation is that @Immutable classes are @ThreadSafe. CSVFormat is not thread-safe, because the fields are not volatile, and the fields are not written read using a common lock. The comment needs to be clarified or removed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SANDBOX-408) CSVFormat describes itself as immutable, but it is not - in particular it is not thread-safe
[ https://issues.apache.org/jira/browse/SANDBOX-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated SANDBOX-408: - Comment: was deleted (was: Another simplification; no need to check for null element.) CSVFormat describes itself as immutable, but it is not - in particular it is not thread-safe Key: SANDBOX-408 URL: https://issues.apache.org/jira/browse/SANDBOX-408 Project: Commons Sandbox Issue Type: Bug Components: CSV Reporter: Sebb Attachments: CSVFormat.java CSVFormat describes itself as immutable, but it is not @Immutable - the class fields are all mutable. The methods that change the fields do so by creating a clone, and returning the changed clone. So in a sense the class is immutable. However, the normal expectation is that @Immutable classes are @ThreadSafe. CSVFormat is not thread-safe, because the fields are not volatile, and the fields are not written read using a common lock. The comment needs to be clarified or removed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SANDBOX-408) CSVFormat describes itself as immutable, but it is not - in particular it is not thread-safe
[ https://issues.apache.org/jira/browse/SANDBOX-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated SANDBOX-408: - Attachment: COLLECTIONS-398-2.patch Another simplification; no need to check for null element. CSVFormat describes itself as immutable, but it is not - in particular it is not thread-safe Key: SANDBOX-408 URL: https://issues.apache.org/jira/browse/SANDBOX-408 Project: Commons Sandbox Issue Type: Bug Components: CSV Reporter: Sebb Attachments: CSVFormat.java CSVFormat describes itself as immutable, but it is not @Immutable - the class fields are all mutable. The methods that change the fields do so by creating a clone, and returning the changed clone. So in a sense the class is immutable. However, the normal expectation is that @Immutable classes are @ThreadSafe. CSVFormat is not thread-safe, because the fields are not volatile, and the fields are not written read using a common lock. The comment needs to be clarified or removed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-218) Introduce new filter input stream with replacement facilities
[
https://issues.apache.org/jira/browse/IO-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb updated IO-218:
Fix Version/s: (was: 2.2)
Introduce new filter input stream with replacement facilities
-
Key: IO-218
URL: https://issues.apache.org/jira/browse/IO-218
Project: Commons IO
Issue Type: Improvement
Components: Filters
Affects Versions: 1.4
Environment: all environments
Reporter: Denis Zhdanov
Attachments: ReplaceFilterInputStream.java,
ReplaceFilterInputStreamTest.java
It seems convenient to have a FilterInputStream that allows to apply
predefined repalcement rules against the read data.
For example we may want to configure the following replacements:
{noformat}
{1, 2} - {7, 8}
{1} - {9}
{3, 2} - {}
{noformat}
and apply them to the input like
{noformat}
{4, 3, 2, 1, 2, 1, 3}
{noformat}
in order to get a result like
{noformat}
{4, 7, 8, 9, 3}
{noformat}
I created the class that allows to do that and attached it to this ticket.
Unit test class at junit4 format is attached as well.
So, the task is to review the provided classes, consider if it's worth to add
them to commons-io distribution and perform the inclusion in the case of
possible result.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-294) Adding FileUtils.byteCountToDisplaySize(long size, boolean useSiUnits)
[
https://issues.apache.org/jira/browse/IO-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb updated IO-294:
Fix Version/s: (was: 2.2)
Adding FileUtils.byteCountToDisplaySize(long size, boolean useSiUnits)
--
Key: IO-294
URL: https://issues.apache.org/jira/browse/IO-294
Project: Commons IO
Issue Type: New Feature
Components: Utilities
Affects Versions: 2.1
Reporter: Jean-Noel Rouvignac
Attachments: FileUtils.java, FileUtilsTest.java
I have written a little Utility method that might benefit Commons IO:
{code}
public class FileUtils {
/**
* Returns a human-readable version of the file size (original is in
bytes). The implementation has the following features:
* ul
* liSupports the SI or IEC units./li
* liSupports I18n/li
* liDisplay a one digit remainder (rounded down if less than 5,
rounded up otherwise)/li
* liOnce the main unit is = 100, drops the remainder which would be
over precision./li
* /ul
*
* @param size The number of bytes.
* @param useSiUnits if false, uses the IEC (International
Electrotechnical Commission) units (powers of 2), else uses SI (International
System of Units)
*units (powers of 10).
* @return A human-readable display value (includes units).
*/
public static String byteCountToDisplaySize(long size, boolean
useSiUnits) {
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (NET-445) The method listFiles in FTPClient can not list these files which upload to FTP Server in Feb, 29 2012
[ https://issues.apache.org/jira/browse/NET-445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated NET-445: - Fix Version/s: (was: 3.1) (was: 3.0.1) The method listFiles in FTPClient can not list these files which upload to FTP Server in Feb, 29 2012 - Key: NET-445 URL: https://issues.apache.org/jira/browse/NET-445 Project: Commons Net Issue Type: Bug Components: FTP Affects Versions: 3.0.1 Reporter: keming.hu Before Feb, 29 2012, the method listFiles() in FTPClient.class can list all files in FTP Server. But today, for any file which be uploaded to FTP Server in Feb, 29 2012, this API can not list these files. When I change the date of FTP Server(it is not Feb, 29 2012), this API can list all files in FTP Server also. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COMPRESS-176) ArchiveInputStream#getNextEntry(): Problems with WinZip directories with Umlauts
[ https://issues.apache.org/jira/browse/COMPRESS-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated COMPRESS-176: -- Attachment: testzap-winzip.zip Copy of test-winzip.zip, but with plain file name changed from 3zip.zip to 3zap.zap. This shows only the plain file name in 7zip and in my copy of Winzip (9.0). This suggests that neither is processing the unicode extra fields. ArchiveInputStream#getNextEntry(): Problems with WinZip directories with Umlauts Key: COMPRESS-176 URL: https://issues.apache.org/jira/browse/COMPRESS-176 Project: Commons Compress Issue Type: Bug Components: Archivers Affects Versions: 1.3 Environment: Windows 7 Reporter: Wurstbrot mit Senf Attachments: test-7zip.zip, test-windows.zip, test-winzip.zip, testzap-winzip.zip There is a problem when handling a WinZip-created zip with Umlauts in directories. I'm accessing a zip file created with WinZip containing a directory with an umlaut (ä) with ArchiveInputStream. When creating the zip file the unicode-flag of winzip had been active. The following problem occurs when accessing the entries of the zip: the ArchiveEntry for a directory containing an umlaut is not marked as a directory and the file names for the directory and all files contained in that directory contain backslashes instead of slashes (i.e. completely different to all other files in directories with no umlaut in their path). There is no difference when letting the ArchiveStreamFactory decide which ArchiveInputStream to create or when using the ZipArchiveInputStream constructor with the correct encoding (I've tried different encodings CP437, CP850, ISO-8859-15, but still the problem persisted). This problem does not occur when using the very same zip file but compressed by 7zip or the built-in Windows 7 zip functionality. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COMPRESS-168) getName of ZipArchiveEntry
[ https://issues.apache.org/jira/browse/COMPRESS-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated COMPRESS-168: -- Issue Type: Bug (was: Test) getName of ZipArchiveEntry -- Key: COMPRESS-168 URL: https://issues.apache.org/jira/browse/COMPRESS-168 Project: Commons Compress Issue Type: Bug Components: Archivers Affects Versions: 1.2 Environment: J2EE Environment with jdk 1.4 Reporter: Pavithra Kumar Attachments: TestZip.zip getName method of ZipArchiveEntry is not giving arabic file names. Instead of that it gives some chunked characters. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (NET-415) typo in migration how-to
[ https://issues.apache.org/jira/browse/NET-415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated NET-415: - Component/s: Docs typo in migration how-to Key: NET-415 URL: https://issues.apache.org/jira/browse/NET-415 Project: Commons Net Issue Type: Improvement Components: Docs Affects Versions: 3.0.1 Environment: All Reporter: george thomas Priority: Trivial Labels: documentation Fix For: 3.1 Please correct occurances to occurrences under the section NetComponents 1.3.8 to Commons Net 1.x on the migration HOWTO page (http://commons.apache.org/net/migration.html) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (NET-73) [net][PATCH] TelnetInputStream.read hangs when socket data ends in a command sequence
[ https://issues.apache.org/jira/browse/NET-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated NET-73: Affects Version/s: 1.4 Fix Version/s: 2.0 1.5 [net][PATCH] TelnetInputStream.read hangs when socket data ends in a command sequence - Key: NET-73 URL: https://issues.apache.org/jira/browse/NET-73 Project: Commons Net Issue Type: Bug Affects Versions: 1.4 Environment: Operating System: other Platform: All Reporter: Rob Hasselbaum Fix For: 1.5, 2.0 Attachments: cmd-seq-hang.patch Background: If one calls TelnetInputStream.read() in single-threaded mode (no reader thread) and there is no data immediately available, the call blocks on a socket read. When data starts to arrive, the stream adds all the available bytes to its internal queue before returning the first one to the caller. To do this, it calls __read() in a loop for as long as there are bytes available. The __read() method returns the first byte of user data from the socket. If __read() encounters a Telnet command sequence (IAC, WILL, WONT, DO, DONT, etc.), it handles the negotiation transparently and then returns the first byte of user data. In most cases, this works fine, but a problem arises if a chunk of data from the remote host ends in a Telnet command sequence. When that happens, the TelnetInputStream.read() method hangs, even though it may have already acquired some user data. This is because it calls __read() in a loop as long as super.available() returns true. But if the remaining data from the socket consists entirely of Telnet commands, __read() will process those AND THEN BLOCK waiting for user data. Just checking super.available() is not sufficient. We should continue the loop only if there are bytes of USER DATA still available from the socket. Not doing this can cause the client to wait indefinitely. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DAEMON-237) ++JvmOptions processed as --JvmOptions
[ https://issues.apache.org/jira/browse/DAEMON-237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated DAEMON-237: Attachment: DAEMON-237.patch The code in prunsrv.c depends on the order of entries in the _commands and _altcmds tables. Looks like some of the checks against lpCmdline-dwCmdIndex were not updated when the option //ES (start) was added to _commands. Patch should fix the issue. ++JvmOptions processed as --JvmOptions -- Key: DAEMON-237 URL: https://issues.apache.org/jira/browse/DAEMON-237 Project: Commons Daemon Issue Type: Bug Components: Procrun Affects Versions: 1.0.8 Environment: XP 64-bit, XP 32-bit, Windows 7 64-bit Reporter: Mark Thomas Attachments: DAEMON-237.patch See https://issues.apache.org/bugzilla/show_bug.cgi?id=52548 and http://tomcat.markmail.org/thread/md3ibbv2w3mxtnb2 for details -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DAEMON-239) prunsrv //ES (start) option not documented
[ https://issues.apache.org/jira/browse/DAEMON-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated DAEMON-239: Affects Version/s: 1.0.8 prunsrv //ES (start) option not documented -- Key: DAEMON-239 URL: https://issues.apache.org/jira/browse/DAEMON-239 Project: Commons Daemon Issue Type: Bug Affects Versions: 1.0.8 Reporter: Sebb -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DAEMON-233) Heap corruption in apxMultiSzToArrayW for windows procrun
[
https://issues.apache.org/jira/browse/DAEMON-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb updated DAEMON-233:
Description:
When I tried to use commons daemon 1.0.8 for a project, after successfully
installing the service, starting it on Windows 7 failed reliably, and it failed
sporadically on other platforms. I traced the problem to a heap corruption bug
due to an over-long pointer write in utils.c, line 321.
The original line (inside of apxMultiSzToArrayW) reads:
AplCopyMemory(p, lpString, (l + 1) * sizeof(WCHAR) + sizeof(WCHAR));
The fix is to remove the + sizeof(WCHAR) from the line, leaving it as
AplCopyMemory(p, lpString, (l + 1) * sizeof(WCHAR));
Note that you've already taken care of the terminating null inside of l.
After I'd made that change and rebuilt, things worked happily for me. Please
could you include this fix in a subsequent release.
To reproduce:
{noformat}
1. Ensure that you do NOT have a JRE or a JDK installed on the target machine.
2. Create a folder structure something like
\MyApp\Jetty
\MyApp\jre7 - copy a JRE into here, but do NOT run the JRE
installation
\MyApp\Jetty\bin -- place prunsrv.exe here
3. Ensure that you do not have the JRE on your system path
4. Install the service via the command line:
C:\MyApp\Jetty\bin\prunsrv.exe install MyService --DisplayName=My Service
--Install=C:\MyApp\Jetty\bin\prunsrv.exe
--LogPath=C:\MyApp\Jetty\logs --LogLevel=Info --StdOutput=auto --StdError=auto
--StartMode=jvm --StopMode=jvm
--JavaHome=C:\MyApp\jre7 --Jvm=C:\MyApp\jre7\bin\client\jvm.dll
--Startup=auto --StartPath=C:\MyApp\Jetty
--Classpath=C:\MyApp\Jetty\start.jar;C:\MyApp\Jetty\commons-daemon-1.0.8.jar
++StartParams=--daemon --StartClass=org.eclipse.jetty.start.Main
--StopClass=org.eclipse.jetty.start.Main ++StopParams=--stop
++JvmOptions=-Djetty.home=C:\MyApp\Jetty ++JvmOptions=-Djetty.port=80
++JvmOptions=-DSTOP.PORT=9131 ++JvmOptions=-DSTOP.KEY=stopMyApp
5. Start the service via net start MyService. Observe that it fails to start.
Depending on the machine, sometimes it started and sometimes it failed to
start.
The joys of heap corruption ...
{noformat}
Anyway, I debugged this with Visual Studio 2010 and used the data change
breakpoint to observe the memory write (2 bytes beyond the end of the allocated
block).
was:
When I tried to use commons daemon 1.0.8 for a project, after successfully
installing the service, starting it on Windows 7 failed reliably, and it failed
sporadically on other platforms. I traced the problem to a heap corruption bug
due to an over-long pointer write in utils.c, line 321.
The original line (inside of apxMultiSzToArrayW) reads:
AplCopyMemory(p, lpString, (l + 1) * sizeof(WCHAR) + sizeof(WCHAR));
The fix is to remove the + sizeof(WCHAR) from the line, leaving it as
AplCopyMemory(p, lpString, (l + 1) * sizeof(WCHAR));
Note that you've already taken care of the terminating null inside of l.
After I'd made that change and rebuilt, things worked happily for me. Please
could you include this fix in a subsequent release.
To reproduce:
1. Ensure that you do NOT have a JRE or a JDK installed on the target machine.
2. Create a folder structure something like
\MyApp\Jetty
\MyApp\jre7 - copy a JRE into here, but do NOT run the JRE
installation
\MyApp\Jetty\bin -- place prunsrv.exe here
3. Ensure that you do not have the JRE on your system path
4. Install the service via the command line:
C:\MyApp\Jetty\bin\prunsrv.exe install MyService --DisplayName=My Service
--Install=C:\MyApp\Jetty\bin\prunsrv.exe --LogPath=C:\MyApp\Jetty\logs
--LogLevel=Info --StdOutput=auto --StdError=auto --StartMode=jvm --StopMode=jvm
--JavaHome=C:\MyApp\jre7 --Jvm=C:\MyApp\jre7\bin\client\jvm.dll
--Startup=auto --StartPath=C:\MyApp\Jetty
--Classpath=C:\MyApp\Jetty\start.jar;C:\MyApp\Jetty\commons-daemon-1.0.8.jar
++StartParams=--daemon --StartClass=org.eclipse.jetty.start.Main
--StopClass=org.eclipse.jetty.start.Main ++StopParams=--stop
++JvmOptions=-Djetty.home=C:\MyApp\Jetty ++JvmOptions=-Djetty.port=80
++JvmOptions=-DSTOP.PORT=9131 ++JvmOptions=-DSTOP.KEY=stopMyApp
5. Start the service via net start MyService. Observe that it fails to start.
Depending on the machine, sometimes it started and sometimes it failed to
start. The joys of heap corruption ...
Anyway, I debugged this with Visual Studio 2010 and used the data change
breakpoint to observe the memory write (2 bytes beyond the end of the allocated
block).
Make command easier to read
Heap corruption in apxMultiSzToArrayW for windows procrun
-
Key: DAEMON-233
URL: https://issues.apache.org/jira/browse/DAEMON-233
Project: Commons Daemon
Issue Type: Bug
Components: Procrun
Affects Versions: 1.0.8
[jira] [Updated] (DAEMON-238) Behaviour of environment variables is not documented, and is unexpected
[ https://issues.apache.org/jira/browse/DAEMON-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated DAEMON-238: Component/s: Procrun Behaviour of environment variables is not documented, and is unexpected --- Key: DAEMON-238 URL: https://issues.apache.org/jira/browse/DAEMON-238 Project: Commons Daemon Issue Type: Bug Components: Procrun Reporter: Sebb The documentation does not currently state whether environment variables are processed before or after command-line options. It appears that they are processed *after* any command-line options, at least in 1.0.7 amd 1.0.8. They completely override the corresponding command-line option in both versions. for example: set PR_JVMOPTION=-Da=1 prunsrv //US//Service --JvmOption -Da=2 ++JvmOption -Db=1 results in -Da=1 only, as does set PR_JVMOPTION=-Da=1 prunsrv //US//Service --JvmOption -Da2=1 ++JvmOption -Db=1 If this really is the intended behaviour, it should be documented as such. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (EMAIL-109) NotificationManager.sendEmail Sending the email to the following server failed : null:25
[ https://issues.apache.org/jira/browse/EMAIL-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated EMAIL-109: --- Comment: was deleted (was: I am out of the office and will return on Monday 16 January 2012 The information contained in this email and any attachments is privileged and confidential and is intended for use only by the addressee. Copying, distributing, or disclosing the information contained in this email and any attachments is prohibited unless expressly authorised by the sender. If you are not the intended recipient, and you have received this message in error - do not read, copy or distribute this email. If you have received this message in error, please delete all copies of this message from your system and notify the sender by return email. It is recommended that you scan this email and any attachments for viruses. Ipswich City Council does not accept liability for any loss or damage incurred directly or indirectly caused by opening this email and/or any attachments. ) NotificationManager.sendEmail Sending the email to the following server failed : null:25 Key: EMAIL-109 URL: https://issues.apache.org/jira/browse/EMAIL-109 Project: Commons Email Issue Type: Bug Reporter: Jaine Steer Assignee: Siegfried Goeschl Priority: Blocker We have a third party product that intermittently does not send emails. One of the application server log files has provided the following clue. I am not very conversant with any versions that we have installed, but will be able to find out anything that is needed if I make a request back through our DBA. The error in the logfile is shown here. 11:21:10 WARN AJPRequestHandler-ApplicationServerThread-11 [ NotificationManager.sendEmail ] Sending the email to the following server failed : null:25 org.apache.commons.mail.EmailException: Sending the email to the following server failed : null:25 at org.apache.commons.mail.Email.sendMimeMessage(Email.java:873) at org.apache.commons.mail.Email.send(Email.java:898) at com.intaz.safetsmart.notification.NotificationManager.sendEmail(NotificationManager.java:204) at com.intaz.safetsmart.notification.NotificationManager.sendNotification(NotificationManager.java:130) at com.intaz.safetsmart.workflow.action.notify.RoleIfIncidentClassification.execute(RoleIfIncidentClassification.java:110) at com.intaz.safetsmart.workflow.Workflow.executeActionHandler(Workflow.java:531) at com.intaz.safetsmart.workflow.Workflow.executeActionHandler(Workflow.java:438) at com.intaz.safetsmart.workflow.WorkflowDefinition.processInitialEvent(WorkflowDefinition.java:308) at com.intaz.safetsmart.workflow.WorkflowDefinition.processInitialEvent(WorkflowDefinition.java:161) at com.intaz.safetsmart.workflow.WorkflowEngine.checkForNewWorkflows(WorkflowEngine.java:180) at com.intaz.safetsmart.workflow.WorkflowEngine.processEvent(WorkflowEngine.java:92) at com.intaz.safetsmart.presentation.generic.WizardObject.save(WizardObject.java:560) at com.intaz.safetsmart.presentation.handler.GenericHandler.handleRequest(GenericHandler.java:469) at com.intaz.safetsmart.presentation.ControllerServlet.performTask(ControllerServlet.java:119) at com.intaz.safetsmart.presentation.BaseServlet.doPost(BaseServlet.java:26) at javax.servlet.http.HttpServlet.service(HttpServlet.java:760) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at com.evermind.server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:824) at com.evermind.server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:330) at com.evermind.server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:830) at com.evermind.server.http.AJPRequestHandler.run(AJPRequestHandler.java:224) at com.evermind.server.http.AJPRequestHandler.run(AJPRequestHandler.java:133) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (NET-434) FTPClient fails to close local listener socket when command socket channel encounter ReadTimeoutException
[
https://issues.apache.org/jira/browse/NET-434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb updated NET-434:
-
Summary: FTPClient fails to close local listener socket when command
socket channel encounter ReadTimeoutException (was: FTP Client not close
local listener socket when command socket channel encounter
ReadTimeoutExceptoin)
FTPClient fails to close local listener socket when command socket channel
encounter ReadTimeoutException
Key: NET-434
URL: https://issues.apache.org/jira/browse/NET-434
Project: Commons Net
Issue Type: Bug
Components: FTP
Affects Versions: 2.2, 3.0.1
Environment: Red Hat Enterprise Linux Server release 5.6 (Tikanga) x64
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: zhangyong
FtpClient connect to an ftp server and login successfully, call
ftpClient.listFiles() method to list remote directory,
and ftp server is vsftp and use active mode.
on commons-net-3.0.1 class org.apache.commons.net.ftp.FTPClient at line 680 :
if (!FTPReply.isPositivePreliminary(sendCommand(command, arg)))
{
server.close();
return null;
}
call sendCommand throw an exception blow:
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:264)
at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158)
at java.io.InputStreamReader.read(InputStreamReader.java:167)
at java.io.BufferedReader.fill(BufferedReader.java:136)
at java.io.BufferedReader.readLine(BufferedReader.java:299)
at java.io.BufferedReader.readLine(BufferedReader.java:362)
at org.apache.commons.net.ftp.FTP.__getReply(FTP.java:299)
at org.apache.commons.net.ftp.FTP.sendCommand(FTP.java:500)
class org.apache.commons.net.ftp.FTPClient at line 648 : ServerSocket server
= _serverSocketFactory_.createServerSocket(getActivePort(), 1,
getHostAddress());
the local listener socket server is not close when sendCommand method
throws exception.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (NET-430) Can't login to POP3S Server using explicit mode
[
https://issues.apache.org/jira/browse/NET-430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb updated NET-430:
-
Summary: Can't login to POP3S Server using explicit mode (was: Can't login
to POP3S Server using explizit mode)
Can't login to POP3S Server using explicit mode
---
Key: NET-430
URL: https://issues.apache.org/jira/browse/NET-430
Project: Commons Net
Issue Type: Bug
Components: POP3
Affects Versions: 3.0.1
Reporter: Thomas Mathis
Priority: Blocker
Login fails if using explizit mode as the reader and writer remain the same
after STLS command.
Take a look at https://issues.apache.org/jira/browse/NET-421 - it's nearly
the same bug.
Bugfix for POP3SClient.java:
{noformat}private void performSSLNegotiation() throws IOException
{
...
_reader = new CRLFLineReader(new InputStreamReader(_input_,
__DEFAULT_ENCODING));
__writer = new BufferedWriter(new OutputStreamWriter(_output_,
__DEFAULT_ENCODING));
}{noformat}
Therefore you have to change some variables in POP3.java from private to
protected.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (NET-429) FTPClient storeFile method creates a file of 0 bytes
[
https://issues.apache.org/jira/browse/NET-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb updated NET-429:
-
Description:
Using the FTPClient object in commons net the way it is shown in the Javadoc
results in a file that is 0 bytes on the remote host. When you get to the
storeFile(..) method, it waits for about 20 seconds before it returns the error
message shown to System.out.
I've tried a number of different things
1. commons-net version 3.0.1 (supposedly had the bug fix for this, but didn't
work for me)
2. [boolean] storeFile (String, InputStream)
3. [OutputStream] storeFile (String)
4. commons-net version 1.4 (still no dice)
5. ftp.connect(server) and ftp.connect(server, 21)
Here's my code:
{noformat}
boolean error = false;
FTPClient ftp = new FTPClient();
InputStream localStream = null;
try {
int reply;
String server = ftp.myserver.com;
ftp.connect(server, 21);
System.out.println(Connected to + server + .);
System.out.print(ftp.getReplyString());
// After connection attempt, you should check the reply
code to
// verify
// success.
reply = ftp.getReplyCode();
if (!FTPReply.isPositiveCompletion(reply)) {
ftp.disconnect();
System.err.println(FTP server refused
connection.);
System.exit(1);
}
boolean wasSuccessful = ftp.login(user, password);
if (!wasSuccessful) {
System.err.println(Login unsuccessful);
System.exit(1);
}
System.out.println(login successful);
String localPath=C:/projects/TEMP/uga.html;
File localFile = new File(localPath);
if (localFile.exists()) {
localStream = new BufferedInputStream(new
FileInputStream(localPath));
wasSuccessful = ftp.storeFile(uga.html,
localStream);
if (!wasSuccessful) {
System.err.println(could not store
file: + localPath);
System.exit(1);
} else {
System.out.println(Successfully saved
file!);
}
}
// transfer files
ftp.logout();
} catch (IOException e) {
error = true;
e.printStackTrace();
} finally {
if (ftp.isConnected()) {
try {
ftp.disconnect();
} catch (IOException ioe) {
// do nothing
}
}
if (localStream != null) {
try {
localStream.close();
} catch (IOException e) {
}
}
System.exit(error ? 1 : 0);
}
{noformat}
Here's my System.out:
{noformat}
Connected to ftp.harmari.com.
220-- Welcome to Pure-FTPd [privsep] [TLS] --
220-You are user number 16 of 500 allowed.
220-Local time is now 05:59. Server port: 21.
220-This is a private system - No anonymous login
220 You will be disconnected after 3 minutes of inactivity.
login successful
could not store file: 2482049866.html
{noformat}
More background:
FileZilla works on my machine
I've also tried the primitive Sun API, and it works perfectly:
{noformat}
try {
url = new
URL(ftp://username:passw...@ftp.myserver.com/offline3/uga.html;type=i;);
URLConnection urlc = url.openConnection();
OutputStream os = urlc.getOutputStream(); // To upload
String localPath = C:/projects/TEMP/uga.html;
InputStream bis = new BufferedInputStream(new
FileInputStream(localPath));
byte[] bstr = new byte[1024];
while (bis.read(bstr) 0) {
os.write(bstr);
}
[jira] [Updated] (NET-423) FTPClient.storeFIle might fail when ControlKeepAliveTimeout is set
[
https://issues.apache.org/jira/browse/NET-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb updated NET-423:
-
Description:
When setting ControlKeepAliveTimeout. FTPClient.__storeFile might fail when
waiting for ack on ControlConnection.
Current code:
{noformat}
// Get the transfer response
boolean ok = completePendingCommand();
if (csl != null) {
csl.cleanUp(); // fetch any outstanding keepalive replies
}
{noformat}
While CSL is active, the ControlConnection timeout is set to 1 sec., if using
default. This timeout value doesn't leave much room in terms of network/end
point latency.
Replacing the code fragment above with the following fragment probably solves
the problem (If proper ControlConnection timeout value is set):
{noformat}
if (csl != null) {
csl.cleanUp(); // fetch any outstanding keepalive replies
}
// Get the transfer response
boolean ok = completePendingCommand();
{noformat}
One workaround is to set ControlKeepAliveReplyTimeout to a higher value.
was:
When setting ControlKeepAliveTimeout. FTPClient.__storeFile might fail when
waiting for ack on ControlConnection.
Current code:
// Get the transfer response
boolean ok = completePendingCommand();
if (csl != null) {
csl.cleanUp(); // fetch any outstanding keepalive replies
}
While CSL is active, the ControlConnection timeout is set to 1 sec., if using
default. This timeout value doesn't leave much room in terms of network/end
point latency.
Replacing the code fragment above with the following fragment probably solves
the problem (If proper ControlConnection timeout value is set):
if (csl != null) {
csl.cleanUp(); // fetch any outstanding keepalive replies
}
// Get the transfer response
boolean ok = completePendingCommand();
One workaround is to set ControlKeepAliveReplyTimeout to a higher value.
FTPClient.storeFIle might fail when ControlKeepAliveTimeout is set
--
Key: NET-423
URL: https://issues.apache.org/jira/browse/NET-423
Project: Commons Net
Issue Type: Bug
Components: FTP
Affects Versions: 3.0.1
Reporter: Jens Koch
Priority: Minor
When setting ControlKeepAliveTimeout. FTPClient.__storeFile might fail when
waiting for ack on ControlConnection.
Current code:
{noformat}
// Get the transfer response
boolean ok = completePendingCommand();
if (csl != null) {
csl.cleanUp(); // fetch any outstanding keepalive replies
}
{noformat}
While CSL is active, the ControlConnection timeout is set to 1 sec., if using
default. This timeout value doesn't leave much room in terms of network/end
point latency.
Replacing the code fragment above with the following fragment probably solves
the problem (If proper ControlConnection timeout value is set):
{noformat}
if (csl != null) {
csl.cleanUp(); // fetch any outstanding keepalive replies
}
// Get the transfer response
boolean ok = completePendingCommand();
{noformat}
One workaround is to set ControlKeepAliveReplyTimeout to a higher value.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (NET-412) Apache Commons TFTP implementation subject to Sorcerer's Apprentice Syndrome
[
https://issues.apache.org/jira/browse/NET-412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb updated NET-412:
-
Description:
This is regarding the org.apache.commons.net.tftp.TFTPClient class.
In the sendFile() method, when a duplicate TFTP ACK is received, the if
(lastBlock == block) section of code fails and control moves to the else
statement. The else block checks to see if the ACK is for the previous DATA
packet, and if so, sends control back to the _sendPacket label where the DATA
packet is resent.
This is in direct violation of Sorcerer's Apprentice Syndrome as defined in RFC
1123 section 4.2.3.1:
the sender (i.e., the side originating the DATA packets) must never resend the
current DATA packet on receipt of a duplicate ACK
The proper else block would look something like this:
{noformat}
{
continue _receivePacket;
}
{noformat}
This enables the client to ignore the duplicated ACK and listen for ACK+1. If
ACK+1 never comes in, the listener should timeout and attempt to resend the
current data packet. As described in NET-410, the TFTP client also does not
properly handle re-transmits either. It is recommended that this issue and
NET-410 be implemented in tandem.
was:
This is regarding the org.apache.commons.net.tftp.TFTPClient class.
In the sendFile() method, when a duplicate TFTP ACK is received, the if
(lastBlock == block) section of code fails and control moves to the else
statement. The else block checks to see if the ACK is for the previous DATA
packet, and if so, sends control back to the _sendPacket label where the DATA
packet is resent.
This is in direct violation of Sorcerer's Apprentice Syndrome as defined in RFC
1123 section 4.2.3.1:
the sender (i.e., the side originating the DATA packets) must never resend the
current DATA packet on receipt of a duplicate ACK
The proper else block would look something like this:
{
continue _receivePacket;
}
This enables the client to ignore the duplicated ACK and listen for ACK+1. If
ACK+1 never comes in, the listener should timeout and attempt to resend the
current data packet. As described in NET-410, the TFTP client also does not
properly handle re-transmits either. It is recommended that this issue and
NET-410 be implemented in tandem.
Apache Commons TFTP implementation subject to Sorcerer's Apprentice Syndrome
Key: NET-412
URL: https://issues.apache.org/jira/browse/NET-412
Project: Commons Net
Issue Type: Bug
Components: TFTP
Affects Versions: 2.2, 3.0
Environment: Java 6 patch 20
Reporter: Chuck Wolber
Priority: Critical
This is regarding the org.apache.commons.net.tftp.TFTPClient class.
In the sendFile() method, when a duplicate TFTP ACK is received, the if
(lastBlock == block) section of code fails and control moves to the else
statement. The else block checks to see if the ACK is for the previous DATA
packet, and if so, sends control back to the _sendPacket label where the DATA
packet is resent.
This is in direct violation of Sorcerer's Apprentice Syndrome as defined in
RFC 1123 section 4.2.3.1:
the sender (i.e., the side originating the DATA packets) must never resend
the current DATA packet on receipt of a duplicate ACK
The proper else block would look something like this:
{noformat}
{
continue _receivePacket;
}
{noformat}
This enables the client to ignore the duplicated ACK and listen for ACK+1. If
ACK+1 never comes in, the listener should timeout and attempt to resend the
current data packet. As described in NET-410, the TFTP client also does not
properly handle re-transmits either. It is recommended that this issue and
NET-410 be implemented in tandem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (NET-382) Subclasses of SocketClient should use _input_ and _output_ rather than calling _socket_.getInputStream() etc
[ https://issues.apache.org/jira/browse/NET-382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated NET-382: - Issue Type: Improvement (was: Bug) Subclasses of SocketClient should use _input_ and _output_ rather than calling _socket_.getInputStream() etc Key: NET-382 URL: https://issues.apache.org/jira/browse/NET-382 Project: Commons Net Issue Type: Improvement Reporter: Sebb Attachments: sockclient-socket-private.diff SocketClient._connectAction() sets up \_input\_ and \_output\_ from \_socket\_ so it is wasteful to do this again in subclasses. Potentially consider making \_socket\_ private? However, this would currently break most of the S versions of the protocols, unless SocketClient is extended to handle their needs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (NET-432) ftp downloads wrong a video
[ https://issues.apache.org/jira/browse/NET-432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated NET-432: - Priority: Minor (was: Critical) ftp downloads wrong a video --- Key: NET-432 URL: https://issues.apache.org/jira/browse/NET-432 Project: Commons Net Issue Type: Bug Components: FTP Affects Versions: 3.0.1 Reporter: john Priority: Minor i got a program that download a reproduct a file from ftp, but the program dont download the video fine, when u try to reproduct with my program or with any reproductor, the file is damager. sorry for my english i speak spanish -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (POOL-205) GKOP - inconsistent synchronisation of poolKeyList
[ https://issues.apache.org/jira/browse/POOL-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated POOL-205: -- Affects Version/s: 2.0 GKOP - inconsistent synchronisation of poolKeyList -- Key: POOL-205 URL: https://issues.apache.org/jira/browse/POOL-205 Project: Commons Pool Issue Type: Bug Affects Versions: 2.0 Reporter: Sebb poolKeyList is an ArrayList - which is not thread-safe. Updates are performed whilst holding the keyLock.writeLock. However, the list is read in evict() without using the same lock, so there's a potential for evict() to see stale or inconsistent state. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JEXL-119) Allow indexed properties container resolution in expressions
[ https://issues.apache.org/jira/browse/JEXL-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated JEXL-119: -- Affects Version/s: (was: 2.1) Allow indexed properties container resolution in expressions Key: JEXL-119 URL: https://issues.apache.org/jira/browse/JEXL-119 Project: Commons JEXL Issue Type: Improvement Affects Versions: 2.0.1 Reporter: Henri Biestro Assignee: Henri Biestro Fix For: 2.1 When a class exposes a pseudo indexed property container, JEXL should be able to introspect and expose it. For instance, given a class exposing the methods 'void setProperty(String name, Object value)' and 'Object getProperty(String name)' and an instance 'o' exposed through the context, JEXL should allow the expressions 'o.property.first' to execute 'o.getProperty(first)' and the expression 'o.property.first = ONE' to execute 'o.setProperty(first, ONE). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JEXL-103) Inputstream reads no byte if it is called into a class runnable
[ https://issues.apache.org/jira/browse/JEXL-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated JEXL-103: -- Fix Version/s: (was: 2.1) Inputstream reads no byte if it is called into a class runnable Key: JEXL-103 URL: https://issues.apache.org/jira/browse/JEXL-103 Project: Commons JEXL Issue Type: Bug Reporter: Cristian Lorenzetto Assignee: Henri Biestro Inputstream instance reads no byte if it is called into a class runnable. if i call the same function in the java code it works , if i call it in the jexl code it enter in the function but than it dont read any bytes in the stream -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JEXL-110) conceptual improvement for the language
[ https://issues.apache.org/jira/browse/JEXL-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated JEXL-110: -- Fix Version/s: (was: 2.1) conceptual improvement for the language --- Key: JEXL-110 URL: https://issues.apache.org/jira/browse/JEXL-110 Project: Commons JEXL Issue Type: Improvement Reporter: Cristian Lorenzetto Assignee: Henri Biestro the language dont distinguish when a object is null and when is undefined we could add a keyword undefined -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JEXL-109) error when i define a variable named LITERAL.LITERAL.
[ https://issues.apache.org/jira/browse/JEXL-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated JEXL-109: -- Fix Version/s: (was: 2.1) error when i define a variable named LITERAL.LITERAL. --- Key: JEXL-109 URL: https://issues.apache.org/jira/browse/JEXL-109 Project: Commons JEXL Issue Type: Bug Reporter: Cristian Lorenzetto -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JEXL-122) Migrate o.a.c.jexl2 to o.a.c.jexl3
[ https://issues.apache.org/jira/browse/JEXL-122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated JEXL-122: -- Fix Version/s: (was: 2.1) Migrate o.a.c.jexl2 to o.a.c.jexl3 -- Key: JEXL-122 URL: https://issues.apache.org/jira/browse/JEXL-122 Project: Commons JEXL Issue Type: Task Reporter: Henri Biestro Assignee: Henri Biestro Since the intended 2.1 release breaks binary and code compatibility, a new package is required for the new version (aka 3.0). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JEXL-122) Migrate o.a.c.jexl2 to o.a.c.jexl3
[ https://issues.apache.org/jira/browse/JEXL-122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated JEXL-122: -- Affects Version/s: 2.1 Migrate o.a.c.jexl2 to o.a.c.jexl3 -- Key: JEXL-122 URL: https://issues.apache.org/jira/browse/JEXL-122 Project: Commons JEXL Issue Type: Task Affects Versions: 2.1 Reporter: Henri Biestro Assignee: Henri Biestro Since the intended 2.1 release breaks binary and code compatibility, a new package is required for the new version (aka 3.0). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-774) Add isStarted isStopped and isSuspended to StopWatch
[ https://issues.apache.org/jira/browse/LANG-774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated LANG-774: -- Attachment: LANG774_2.patch Yes, I think that does look much better. But rather than have static enum methods, it might be nicer to have the enums themselves define their state. See my alternative patch (based on your enum patch) Add isStarted isStopped and isSuspended to StopWatch Key: LANG-774 URL: https://issues.apache.org/jira/browse/LANG-774 Project: Commons Lang Issue Type: Improvement Components: lang.time.* Affects Versions: 3.1 Reporter: Michael Akerman Priority: Minor Labels: features Fix For: 3.2 Attachments: LANG774.diff, LANG774_1.diff, LANG774_2.patch, StopWatch.java Original Estimate: 2h Remaining Estimate: 2h It would be nice to have: isStarted isStopped isSuspended On StopWatch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DAEMON-229) Windows 2003 server 64bit and JDK1.6.0_29 64bit -- Failed creating java
[
https://issues.apache.org/jira/browse/DAEMON-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb updated DAEMON-229:
Affects Version/s: (was: 1.0.8)
1.0.7
bq. Commons Daemon procrun (1.0.7.0 32-bit) started
Also note that you are not using the current version (1.0.8)
Windows 2003 server 64bit and JDK1.6.0_29 64bit -- Failed creating java
---
Key: DAEMON-229
URL: https://issues.apache.org/jira/browse/DAEMON-229
Project: Commons Daemon
Issue Type: Bug
Components: Procrun
Affects Versions: 1.0.7
Environment: Windows 2003 server 64bit
Sun JDK1.6.0_29 64bit
Reporter: Apache Fan
I tried to install Commons Daemon on 64 bit Windows 2003 Server with JDK
1.6.0_29 64 bit.
During starting a service (Cassandra) I receive the error log below.
As a workaround I installed 32 bit JVM, and configured the
\jre6\bin\client\jvm.dll as JVM with the prunmgr //ES//servicename
(Hint found at
http://www.mkyong.com/tomcat/tomcat-error-prunsrvc-failed-creating-java-jvmdll/
)
Compatibility with 64 bit JVM should be established.
{noformat}
[2011-11-25 02:50:51] [debug] ( prunsrv.c:1519) Commons Daemon procrun log
initialized
[2011-11-25 02:50:51] [info] ( :0 ) Commons Daemon procrun
(1.0.7.0 32-bit) started
[2011-11-25 02:50:51] [info] ( :0 ) Running 'cassandra' Service...
[2011-11-25 02:50:51] [debug] ( prunsrv.c:1259) Inside ServiceMain...
[2011-11-25 02:50:51] [info] ( :0 ) Starting service...
[2011-11-25 02:50:51] [debug] ( javajni.c:206 ) loading jvm
'D:\apps\jre6\bin\server\jvm.dll'
[2011-11-25 02:50:52] [debug] ( javajni.c:251 ) Setting DLL search path to
'D:\apps\jre6\bin\server'
[2011-11-25 02:50:52] [debug] ( javajni.c:251 ) Setting DLL search path to
'D:\apps\jre6\bin'
[2011-11-25 02:50:52] [error] ( javajni.c:264 ) %1 is not a valid Win32
application.
[2011-11-25 02:50:52] [error] ( prunsrv.c:1045) Failed creating java
D:\apps\jre6\bin\server\jvm.dll
[2011-11-25 02:50:52] [error] ( prunsrv.c:1045) %1 is not a valid Win32
application.
[2011-11-25 02:50:52] [error] ( prunsrv.c:1402) ServiceStart returned 1
[2011-11-25 02:50:52] [error] ( prunsrv.c:1402) %1 is not a valid Win32
application.
[2011-11-25 02:50:52] [info] ( :0 ) Run service finished.
[2011-11-25 02:50:52] [info] ( :0 ) Commons Daemon procrun
finished
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DAEMON-215) Cannot set local username and password for a Win32 service
[ https://issues.apache.org/jira/browse/DAEMON-215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated DAEMON-215: Fix Version/s: (was: 1.0.7) 1.0.8 Cannot set local username and password for a Win32 service -- Key: DAEMON-215 URL: https://issues.apache.org/jira/browse/DAEMON-215 Project: Commons Daemon Issue Type: Bug Components: Procrun Affects Versions: 1.0.7 Environment: win32 / server 2003 Reporter: wessels Assignee: Mladen Turk Priority: Minor Fix For: 1.0.8 Original Estimate: 24h Remaining Estimate: 24h installing a new service without supplying the --ServiceUser --ServicePassword installs the service correctly but using the LocalSystem account. If you want to use a local user, which of course has at least the log on as a service right, and supply the credentials via the parameters you get an error. To be more specific, in service.c line 211, the CHANGE_SERVICE macro fails with error 87L ERROR_INVALID_PARAMETER. This happens at least when creating and updating a service. Setting other options via this macro work fine, just the username password fail (standalone and in combination with other parameters). The solution is specifying SERVICE_WIN32_OWN_PROCESS as ServiceType parameter instead of SERVICE_NO_CHANGE in ChangeServiceConfigW line 27 second parameter. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DAEMON-218) CLONE - procrun as tomcat5.exe from Tomcat 5.5.17 does not start, when installed into the file path containing non-ascii character
[ https://issues.apache.org/jira/browse/DAEMON-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated DAEMON-218: Affects Version/s: 1.0.7 Fix Version/s: (was: 1.0.7) 1.0.8 CLONE - procrun as tomcat5.exe from Tomcat 5.5.17 does not start, when installed into the file path containing non-ascii character -- Key: DAEMON-218 URL: https://issues.apache.org/jira/browse/DAEMON-218 Project: Commons Daemon Issue Type: Bug Affects Versions: 1.0.7 Reporter: Alexey Grishkov Assignee: Mladen Turk Fix For: 1.0.8 Attachments: prunsrv.c, utils.c Tomcat Service can not be started if Tomcat was installed into the path, containing non-ASCII (e.g. Japanese or Chinese) symbols. The problem is apparently due to the improper treatment of non-ascii characters in the Java classpath section of the Service settings. In tomcat5w.exe GUI or windows registry I could see proper PATH, namely C:\[ONE CHINESE HIEROGLIPH]\Tomcat 5.5\bin\bootstrap.jar Unfortunately, service doesn't get started with the following log: [2006-09-15 18:29:17] [457 javajni.c] [error] FindClass org/apache/catalina/startup/Bootstrap failed [2006-09-15 18:29:17] [935 prunsrv.c] [error] Failed loading main org/apache/catalina/startup/Bootstrap class C:\ss\Tomcat 5.5\bin\bootstrap.jar [2006-09-15 18:29:17] [1179 prunsrv.c] [error] ServiceStart returned 3 where the non-ascii symbol gets replaced with improper ascii 'ss' sequence. Moreover, I tried to define environmental variables PR_CLASSPATH and PR_STARTPATH instead of using corresponding service params. The result is exactly the same. Please, suggest me the workaround to make Tomcat service run. P.S. The problem is stable either under JRE 1.5.0_02 or 1.4.2_10 (within tomcat compatibility package). The problem exist apparently under all OS (in particular, it was detected on Windows 2000 and Windows XP Pro 2002 SP2 either Chinese version or standard English with Chinese System locale installed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (NET-425) _openDataConnection_, __storeFile, and __storeFileStream should be protected and take String for FTP command.
[ https://issues.apache.org/jira/browse/NET-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated NET-425: - Affects Version/s: 3.0.1 Fix Version/s: 3.1 _openDataConnection_, __storeFile, and __storeFileStream should be protected and take String for FTP command. - Key: NET-425 URL: https://issues.apache.org/jira/browse/NET-425 Project: Commons Net Issue Type: Improvement Components: FTP Affects Versions: 3.0.1 Environment: All Reporter: Steven Jardine Fix For: 3.1 Attachments: patch.txt Currently __storeFile, __storeStream, and _openConnection_ are declared as private and only receive int commands. I am trying to extend the FTPClient class to implement specialized commands that utilize these methods. In order for this to work I need to have these methods declared as protected as well as adjust the parameters to allow for String commands. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (NET-428) SubnetUtils throws ArrayIndexOutOfBoundsException for new SubnetUtils( 1.2.3.4/32 ).getInfo().getAllAddresses()
[ https://issues.apache.org/jira/browse/NET-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated NET-428: - Fix Version/s: 3.1 SubnetUtils throws ArrayIndexOutOfBoundsException for new SubnetUtils( 1.2.3.4/32 ).getInfo().getAllAddresses() - Key: NET-428 URL: https://issues.apache.org/jira/browse/NET-428 Project: Commons Net Issue Type: Bug Affects Versions: 3.0.1 Reporter: Sebb Fix For: 3.1 new SubnetUtils( 1.2.3.4/32 ).getInfo().getAllAddresses() throws Exception in thread main java.lang.ArrayIndexOutOfBoundsException: 0 $SubnetInfo.getAllAddresses(SubnetUtils.java:166) Similarly for /31 It would make more sense to return an empty array. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (NET-415) typo in migration how-to
[ https://issues.apache.org/jira/browse/NET-415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated NET-415: - Affects Version/s: 3.0.1 Fix Version/s: 3.1 typo in migration how-to Key: NET-415 URL: https://issues.apache.org/jira/browse/NET-415 Project: Commons Net Issue Type: Improvement Affects Versions: 3.0.1 Environment: All Reporter: george thomas Priority: Trivial Labels: documentation Fix For: 3.1 Please correct occurances to occurrences under the section NetComponents 1.3.8 to Commons Net 1.x on the migration HOWTO page (http://commons.apache.org/net/migration.html) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (NET-416) Increasing sub-negotiation message holder array size
[ https://issues.apache.org/jira/browse/NET-416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated NET-416: - Fix Version/s: 3.1 Increasing sub-negotiation message holder array size Key: NET-416 URL: https://issues.apache.org/jira/browse/NET-416 Project: Commons Net Issue Type: Improvement Components: Telnet Affects Versions: 3.0, 3.0.1 Environment: Linux Reporter: Abhijeet Gaikwad Labels: authentication, linux, ntlm, telnet Fix For: 3.1 Attachments: NTLM_Auth_Support.patch Original Estimate: 1h Remaining Estimate: 1h I am trying to achieve NTLM Authentication by extending the Telnet option handler. The challenge sent by the telnet server is greater than 256 bytes, but currently the __suboption[] array in TelnetInputStream supports only a 256 bytes message. If I increase the size of the array to 512, I am able to achieve NTLM Authentication. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (NET-231) ParserInitializationException for a couple of server types (AS/400 and UNKNOWN Type: L8)
[
https://issues.apache.org/jira/browse/NET-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb updated NET-231:
-
Fix Version/s: 1.5
ParserInitializationException for a couple of server types (AS/400 and
UNKNOWN Type: L8)
Key: NET-231
URL: https://issues.apache.org/jira/browse/NET-231
Project: Commons Net
Issue Type: Bug
Affects Versions: 1.4
Reporter: Rob Weaver
Priority: Minor
Fix For: 1.5
Attachments: type_l8_1.5.patch
Was getting an error when connecting to one of our vendor file servers that
was returning 215 UNKNOWN Type: L8 for a SYST command.
The DefaultFTPFileEntryParserFactory does a toUpperCase on the key, which was
then being compared to the constant SYST_L8.
That constant was Type: L8, so it could never match.
Also some systems respond as AS/400 instead of OS/400, so added the check
for that string.
Patch below and attached for 1.5, see issue NET-320 for patch for 2.0
# This patch file was generated by NetBeans IDE
# Following Index: paths are relative to: C:\Documents and Settings\robw\My
Documents\NetBeansProjects\trunk
# This patch can be applied using context Tools: Patch action on respective
folder.
# It uses platform neutral UTF-8 encoding and \n newlines.
# Above lines and this line are ignored by the patching process.
Index: src/java/org/apache/commons/net/ftp/FTPClientConfig.java
--- src/java/org/apache/commons/net/ftp/FTPClientConfig.java Base (BASE)
+++ src/java/org/apache/commons/net/ftp/FTPClientConfig.java Locally Modified
(Based On LOCAL)
@@ -171,7 +171,13 @@
*/
public static final String SYST_OS400 = OS/400;
+
/**
+ * Alternate SYST value for an AS/400 system.
+ */
+public static final String SYST_AS400 = AS/400;
+
+/**
* Identifier by which an MVS-based ftp server is known throughout
* the commons-net ftp system.
*/
@@ -185,7 +191,7 @@
*
* @since 1.5
*/
-public static final String SYST_L8 = Type: L8;
+public static final String SYST_L8 = TYPE: L8;
/**
* Identifier by which an Netware-based ftp server is known throughout
Index:
src/java/org/apache/commons/net/ftp/parser/DefaultFTPFileEntryParserFactory.java
---
src/java/org/apache/commons/net/ftp/parser/DefaultFTPFileEntryParserFactory.java
Base (BASE)
+++
src/java/org/apache/commons/net/ftp/parser/DefaultFTPFileEntryParserFactory.java
Locally Modified (Based On LOCAL)
@@ -109,7 +109,8 @@
{
parser = createOS2FTPEntryParser();
}
-else if (ukey.indexOf(FTPClientConfig.SYST_OS400) = 0)
+else if ((ukey.indexOf(FTPClientConfig.SYST_OS400) = 0)
+|| (ukey.indexOf(FTPClientConfig.SYST_AS400) = 0))
{
parser = createOS400FTPEntryParser();
}
Index:
src/test/org/apache/commons/net/ftp/parser/DefaultFTPFileEntryParserFactoryTest.java
---
src/test/org/apache/commons/net/ftp/parser/DefaultFTPFileEntryParserFactoryTest.java
Base (BASE)
+++
src/test/org/apache/commons/net/ftp/parser/DefaultFTPFileEntryParserFactoryTest.java
Locally Modified (Based On LOCAL)
@@ -62,6 +62,15 @@
parser = factory.createFileEntryParser(OS/400);
assertTrue(parser instanceof CompositeFileEntryParser);
+parser = factory.createFileEntryParser(AS/400);
+assertTrue(parser instanceof CompositeFileEntryParser);
+
+// Added test to make sure it handles the Unix systems that were
+// compiled with OS as UNKNOWN. This test validates that the
+// check is case-insensitive.
+parser = factory.createFileEntryParser(UNKNOWN Type: L8);
+
+
try {
parser = factory.createFileEntryParser(OS2FTPFileEntryParser);
fail(Exception should have been thrown.
\OS2FTPFileEntryParser\ is not a recognized key);
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DAEMON-223) configure script has incorrect supported OS for HP-UX on IA64
[ https://issues.apache.org/jira/browse/DAEMON-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated DAEMON-223: Fix Version/s: 1.0.8 configure script has incorrect supported OS for HP-UX on IA64 - Key: DAEMON-223 URL: https://issues.apache.org/jira/browse/DAEMON-223 Project: Commons Daemon Issue Type: Bug Components: Jsvc Affects Versions: 1.0.7 Reporter: Michael Osipov Assignee: Mladen Turk Priority: Critical Fix For: 1.0.8 Attachments: DAEMON-223.patch The apsupport.m4 file has an incorrect supported_os value for HP-UX on Itanium. java_md.h cannot be found. I have unified the property for all HP-UX systems. It should cover all cases now. jsvc compiles out of the box now on HP-UX 11.x. The supplied patch is attached. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DAEMON-222) Remove 'procname' option with preprocessor condition if OS is not Linux
[ https://issues.apache.org/jira/browse/DAEMON-222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated DAEMON-222: Fix Version/s: (was: 1.0.7) 1.0.8 Remove 'procname' option with preprocessor condition if OS is not Linux --- Key: DAEMON-222 URL: https://issues.apache.org/jira/browse/DAEMON-222 Project: Commons Daemon Issue Type: Improvement Components: Jsvc Affects Versions: 1.0.7 Reporter: Michael Osipov Assignee: Mladen Turk Fix For: 1.0.8 The procname option can only be used on Linux. It would be removed by the preprocessor if the target OS is not Linux. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DAEMON-221) Provide umask rather than compile time flag for umask
[ https://issues.apache.org/jira/browse/DAEMON-221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated DAEMON-221: Fix Version/s: 1.0.8 Provide umask rather than compile time flag for umask - Key: DAEMON-221 URL: https://issues.apache.org/jira/browse/DAEMON-221 Project: Commons Daemon Issue Type: Improvement Components: Jsvc Affects Versions: 1.0.7 Reporter: Michael Osipov Assignee: Mladen Turk Fix For: 1.0.8 umask can only be modified at compile time with -DUMASK... this is somewhat annoying. Please include a -umask option which takes in a octal number. A sane umask (0777) should remain of course. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DAEMON-222) Remove 'procname' option with preprocessor condition if OS is not Linux
[ https://issues.apache.org/jira/browse/DAEMON-222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated DAEMON-222: Fix Version/s: (was: 1.0.8) Remove 'procname' option with preprocessor condition if OS is not Linux --- Key: DAEMON-222 URL: https://issues.apache.org/jira/browse/DAEMON-222 Project: Commons Daemon Issue Type: Improvement Components: Jsvc Affects Versions: 1.0.7 Reporter: Michael Osipov Assignee: Mladen Turk The procname option can only be used on Linux. It would be removed by the preprocessor if the target OS is not Linux. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DAEMON-220) Clean up configure/configure.in scripts
[ https://issues.apache.org/jira/browse/DAEMON-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated DAEMON-220: Fix Version/s: 1.0.8 Clean up configure/configure.in scripts --- Key: DAEMON-220 URL: https://issues.apache.org/jira/browse/DAEMON-220 Project: Commons Daemon Issue Type: Improvement Components: Jsvc Affects Versions: 1.0.7 Reporter: Michael Osipov Assignee: Mladen Turk Fix For: 1.0.8 Attachments: DAEMON-220.patch The current configure script has several deficiencies at the moment.No CPPFLAGS support, no detection of Java OS. Most can be taken from libtcnative. Issue has been raised on the mailing list: http://www.mail-archive.com/user@commons.apache.org/msg07101.html It needs a complete overhaul. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DAEMON-215) Cannot set local username and password for a Win32 service
[ https://issues.apache.org/jira/browse/DAEMON-215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated DAEMON-215: Fix Version/s: (was: 1.0.7) Cannot set local username and password for a Win32 service -- Key: DAEMON-215 URL: https://issues.apache.org/jira/browse/DAEMON-215 Project: Commons Daemon Issue Type: Bug Components: Procrun Affects Versions: 1.0.7 Environment: win32 / server 2003 Reporter: wessels Assignee: Mladen Turk Priority: Minor Original Estimate: 24h Remaining Estimate: 24h installing a new service without supplying the --ServiceUser --ServicePassword installs the service correctly but using the LocalSystem account. If you want to use a local user, which of course has at least the log on as a service right, and supply the credentials via the parameters you get an error. To be more specific, in service.c line 211, the CHANGE_SERVICE macro fails with error 87L ERROR_INVALID_PARAMETER. This happens at least when creating and updating a service. Setting other options via this macro work fine, just the username password fail (standalone and in combination with other parameters). The solution is specifying SERVICE_WIN32_OWN_PROCESS as ServiceType parameter instead of SERVICE_NO_CHANGE in ChangeServiceConfigW line 27 second parameter. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DAEMON-213) procun log rotation support
[ https://issues.apache.org/jira/browse/DAEMON-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated DAEMON-213: Fix Version/s: (was: Nightly Builds) procun log rotation support --- Key: DAEMON-213 URL: https://issues.apache.org/jira/browse/DAEMON-213 Project: Commons Daemon Issue Type: Improvement Components: Procrun Affects Versions: 1.0.4, 1.0.5, 1.0.6 Environment: os: winxp Reporter: viola.lu Priority: Minor currently, procun doesn't support log rotation. Should add an option -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CONFIGURATION-465) OSGI issue - configuration depends on Jexl 1.0 which does not have OSGI release
[ https://issues.apache.org/jira/browse/CONFIGURATION-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated CONFIGURATION-465: --- Summary: OSGI issue - configuration depends on Jexl 1.0 which does not have OSGI release (was: commons-configuration ) OSGI issue - configuration depends on Jexl 1.0 which does not have OSGI release --- Key: CONFIGURATION-465 URL: https://issues.apache.org/jira/browse/CONFIGURATION-465 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.7 Reporter: Rich Mayfield I updated to use commons-configuration 1.7 (from 1.6) and am running into the following resolution error under Eclipse Equinox OSGi framework. An Import-Package could not be resolved. Caused by missing constraint in bundle org.apache.commons.configuration_1.7.0 constraint: Import-Package: org.apache.commons.jexl; version=0.0.0 According to the Import-Package header in 1.7's MANIFEST.MF, commons-configuration now has a required dependency on org.apache.commons.jexl. Problem is, there is no OSGi enabled version of Apache Commons jexl that exports this package. In jexl 2.0 the packages were renamed and org.apache.commons.jexl2 is exported. The 1.x codeline, although using org.apache.commons.jexl, does not have the appropriate MANIFEST.MF headers to be used as an OSGi bundle. As such, you cannot consume commons-configuration 1.7 in an OSGi environment. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
