[jira] [Created] (VFS-459) Log sent FTP/FTPS commands and received answers
Joerg Schaible created VFS-459: -- Summary: Log sent FTP/FTPS commands and received answers Key: VFS-459 URL: https://issues.apache.org/jira/browse/VFS-459 Project: Commons VFS Issue Type: Improvement Affects Versions: 2.0 Reporter: Joerg Schaible Assignee: Joerg Schaible Priority: Trivial Fix For: 2.1 Log the sent FTP/FTPS commands and the received answers at debug level. Since commons-net does not support logging on its own, it is the task of VFS as its client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (VFS-459) Log sent FTP/FTPS commands and received answers
[ https://issues.apache.org/jira/browse/VFS-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joerg Schaible resolved VFS-459. Resolution: Fixed $ svn ci -m "Sent FTP/FTPS commands and the received answer is logged at debug level (VFS-459)." Sending core/src/main/java/org/apache/commons/vfs2/provider/ftp/FtpClientFactory.java Sendingsrc/changes/changes.xml Transmitting file data .. Committed revision 1448560. > Log sent FTP/FTPS commands and received answers > --- > > Key: VFS-459 > URL: https://issues.apache.org/jira/browse/VFS-459 > Project: Commons VFS > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Joerg Schaible >Assignee: Joerg Schaible >Priority: Trivial > Fix For: 2.1 > > > Log the sent FTP/FTPS commands and the received answers at debug level. Since > commons-net does not support logging on its own, it is the task of VFS as its > client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (VFS-460) commons-compress not optional
Joerg Schaible created VFS-460: -- Summary: commons-compress not optional Key: VFS-460 URL: https://issues.apache.org/jira/browse/VFS-460 Project: Commons VFS Issue Type: Bug Affects Versions: 2.0 Reporter: Joerg Schaible Fix For: 2.1 commons-compress dependency is not declared as optional. On purpose or plain oversight? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (EMAIL-124) Header values are folded twice and thus creating defective emails
Stefan Schueffler created EMAIL-124: --- Summary: Header values are folded twice and thus creating defective emails Key: EMAIL-124 URL: https://issues.apache.org/jira/browse/EMAIL-124 Project: Commons Email Issue Type: Bug Affects Versions: 1.3 Reporter: Stefan Schueffler Priority: Blocker With EMAIL-98, header values now are folded by commons-email. Unfortunately, they are folded twice: once in "Mail.addHeader" or "Mail.setHeaders", and once again in "Mail.buildMimeMessage()" while iterating over the headers. This results (in our test cases) in corrupted mail header lines having additional blank lines between the first and second line of a folded value - and thus ends in corrupted mails (as all headers after the first blank line are threatened as mail-body-content). As this renders "additional headers" useless in commons-mail and corrupts every mail having additionl headers with longer-than-folding-size values, i set the priority to blocker. The fix seems to be easy: just fold either in addHeader and setHeaders, or in buildMimeMessage (but not in both). My preferred solution would be to fold in buildMimeMessage, and to store the values "as-is" in addHeader and setHeaders so one is able to work with the plain values (if neccessary) until the mail is actually build and send. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COMPRESS-219) ZipArchiveInputStream: ArrayIndexOutOfBoundsException when extracting a STORED zip file entry from within a zip.
[ https://issues.apache.org/jira/browse/COMPRESS-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13583100#comment-13583100 ] Wurstbrot mit Senf commented on COMPRESS-219: - Yes, of course you can include it. It does not contain any sensitive data, in fact, no "data" at all :-) > ZipArchiveInputStream: ArrayIndexOutOfBoundsException when extracting a > STORED zip file entry from within a zip. > > > Key: COMPRESS-219 > URL: https://issues.apache.org/jira/browse/COMPRESS-219 > Project: Commons Compress > Issue Type: Bug > Components: Archivers >Affects Versions: 1.4.1 > Environment: Windows (Linux as well) >Reporter: Wurstbrot mit Senf >Priority: Minor > Fix For: 1.5 > > Attachments: compress-219-test.patch, test-linux.zip, > ZipArchiveInputStreamTest.java > > > When trying to read out a ZIP file, that has been stored (Method STORE, not > DEFLATE!, with DEFLATE it seems OK) in another ZIP file using the > ZipArchiveInputStream, I do get an ArrayIndexOutOfBoundsException when doing > the arraycopy in ZipArchiveInputStream#readStored(byte[], int, int) (line > 362) because the "toRead" is not decreased by the buf.offsetInBuffer. > I will add the zip in question as attachment. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (VFS-412) [FTPS] Support to send execPROT("P")
[
https://issues.apache.org/jira/browse/VFS-412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joerg Schaible resolved VFS-412.
Resolution: Fixed
Fix Version/s: 2.1
Assignee: Joerg Schaible
Applied, but I've changed the level values from String to an enum. I did not
provide an additional setting for the buffer size, because it is normally set
to 0 anyway representing data streaming.
$ svn ci -m "Add support for FTPS command to set the DataChannelProtectionLevel
(VFS-412)."
Sendingcore/src/main/java/org/apache/commons/vfs2/Resources.properties
Sending
core/src/main/java/org/apache/commons/vfs2/provider/ftp/FtpClientFactory.java
Sending
core/src/main/java/org/apache/commons/vfs2/provider/ftps/FtpsClientFactory.java
Adding
core/src/main/java/org/apache/commons/vfs2/provider/ftps/FtpsDataChannelProtectionLevel.java
Sending
core/src/main/java/org/apache/commons/vfs2/provider/ftps/FtpsFileSystemConfigBuilder.java
Sending
core/src/test/java/org/apache/commons/vfs2/provider/ftps/test/AbstractFtpsProviderTestCase.java
Sending
core/src/test/java/org/apache/commons/vfs2/provider/ftps/test/FtpsProviderExplicitTestCase.java
Sending
core/src/test/java/org/apache/commons/vfs2/provider/ftps/test/FtpsProviderImplicitTestCase_Disabled.java
Sendingpom.xml
Sendingsrc/changes/changes.xml
Transmitting file data ..
Committed revision 1448606.
> [FTPS] Support to send execPROT("P")
>
>
> Key: VFS-412
> URL: https://issues.apache.org/jira/browse/VFS-412
> Project: Commons VFS
> Issue Type: Improvement
>Reporter: Jose Juan Montiel
>Assignee: Joerg Schaible
>Priority: Minor
> Labels: patch
> Fix For: 2.1
>
> Attachments: patch_412.txt, patch_exexprot.txt
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The layer over FTPSClient can't permit to send a client.execPROT("P") and
> this make in FTPS explicit (with vsFTPd 2.0.7) make an error:
> SSL version: TLSv1/SSLv3, SSL cipher: DES-CBC3-SHA, not reused, no cert
> 522 Data connections must be encrypted.
> The patch offer via FtpsFileSystemConfigBuilder the option to set execPROT
> like do with setPassiveMode.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (EMAIL-124) Header values are folded twice and thus creating defective emails
[ https://issues.apache.org/jira/browse/EMAIL-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved EMAIL-124. --- Resolution: Fixed Fix Version/s: 1.3.1 Fixed in r1448617. Thanks for the report and analysis, we will try to push a 1.3.1 bugfix release for it. > Header values are folded twice and thus creating defective emails > - > > Key: EMAIL-124 > URL: https://issues.apache.org/jira/browse/EMAIL-124 > Project: Commons Email > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Stefan Schueffler >Priority: Blocker > Fix For: 1.3.1 > > Original Estimate: 5m > Remaining Estimate: 5m > > With EMAIL-98, header values now are folded by commons-email. > Unfortunately, they are folded twice: once in "Mail.addHeader" or > "Mail.setHeaders", and once again in "Mail.buildMimeMessage()" while > iterating over the headers. > This results (in our test cases) in corrupted mail header lines having > additional blank lines between the first and second line of a folded value - > and thus ends in corrupted mails (as all headers after the first blank line > are threatened as mail-body-content). > As this renders "additional headers" useless in commons-mail and corrupts > every mail having additionl headers with longer-than-folding-size values, i > set the priority to blocker. > The fix seems to be easy: just fold either in addHeader and setHeaders, or in > buildMimeMessage (but not in both). > My preferred solution would be to fold in buildMimeMessage, and to store the > values "as-is" in addHeader and setHeaders so one is able to work with the > plain values (if neccessary) until the mail is actually build and send. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VFS-460) commons-compress not optional
[ https://issues.apache.org/jira/browse/VFS-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13583185#comment-13583185 ] Gary Gregory commented on VFS-460: -- Well, no dependency is declared as optional... > commons-compress not optional > - > > Key: VFS-460 > URL: https://issues.apache.org/jira/browse/VFS-460 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Joerg Schaible > Fix For: 2.1 > > > commons-compress dependency is not declared as optional. On purpose or plain > oversight? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VFS-460) commons-compress not optional
[ https://issues.apache.org/jira/browse/VFS-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13583186#comment-13583186 ] Gary Gregory commented on VFS-460: -- Well, no dependency is declared as optional... > commons-compress not optional > - > > Key: VFS-460 > URL: https://issues.apache.org/jira/browse/VFS-460 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Joerg Schaible > Fix For: 2.1 > > > commons-compress dependency is not declared as optional. On purpose or plain > oversight? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VFS-460) commons-compress not optional
[
https://issues.apache.org/jira/browse/VFS-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13583191#comment-13583191
]
Joerg Schaible commented on VFS-460:
from core/pom.xml, non-test dependencies:
{noformat}
commons-logging
commons-logging
ant
ant
true
commons-net
commons-net
true
org.apache.commons
commons-compress
commons-collections
commons-collections
true
commons-httpclient
commons-httpclient
true
org.apache.jackrabbit
jackrabbit-webdav
true
com.jcraft
jsch
true
{noformat}
> commons-compress not optional
> -
>
> Key: VFS-460
> URL: https://issues.apache.org/jira/browse/VFS-460
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Joerg Schaible
> Fix For: 2.1
>
>
> commons-compress dependency is not declared as optional. On purpose or plain
> oversight?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Deleted] (VFS-460) commons-compress not optional
[ https://issues.apache.org/jira/browse/VFS-460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joerg Schaible updated VFS-460: --- Comment: was deleted (was: Well, no dependency is declared as optional...) > commons-compress not optional > - > > Key: VFS-460 > URL: https://issues.apache.org/jira/browse/VFS-460 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Joerg Schaible > Fix For: 2.1 > > > commons-compress dependency is not declared as optional. On purpose or plain > oversight? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (VFS-461) [FTP/FTPS] Cannot set SoTimeout and Encoding with system properties
Joerg Schaible created VFS-461: -- Summary: [FTP/FTPS] Cannot set SoTimeout and Encoding with system properties Key: VFS-461 URL: https://issues.apache.org/jira/browse/VFS-461 Project: Commons VFS Issue Type: Bug Affects Versions: 2.0 Reporter: Joerg Schaible Assignee: Joerg Schaible Priority: Trivial Fix For: 2.1 FtpFileSystemConfigBuilder does not consider system properties for the configuration values of the SoTimeout and the Encoding. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LOGGING-119) deadlock on re-registration of logger
[
https://issues.apache.org/jira/browse/LOGGING-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13583208#comment-13583208
]
Jesse Glick commented on LOGGING-119:
-
FYI, affects Jenkins with embedded Maven:
https://issues.jenkins-ci.org/browse/JENKINS-15846; might affect command-line
Maven but the trigger conditions may not be present.
Two points related to this bug:
- Why does {{LogFactory}} require the value of its
{{….LogFactory.HashtableImpl}} property to be a {{Hashtable}} rather than
simply a {{Map}}?
- If the answer to the first question is “no good reason”, why do you not
simply use {{java.util.WeakHashMap}} (possibly with a synchronization wrapper)
rather than writing your own {{WeakHashtable}}?
> deadlock on re-registration of logger
> -
>
> Key: LOGGING-119
> URL: https://issues.apache.org/jira/browse/LOGGING-119
> Project: Commons Logging
> Issue Type: Bug
>Affects Versions: 1.1.1
> Environment: Java 1.5, Windows
>Reporter: Nitzan Niv
> Fix For: 1.1.2
>
> Attachments: BugDeadlock.java, Patch-WeakHashtable-1.1.1.txt
>
>
> Reached a deadlock inside common-logging while concurrently re-deploying 2
> WARs.
> In each WAR there is an attempt to get a logger:
> private final Log logger = LogFactory.getLog(ContextLoader.class);
> Thread dump:
> [deadlocked thread] Thread-96:
> -
> Thread 'Thread-96' is waiting to acquire lock
> 'java.lang.ref.ReferenceQueue@5266e0' that is held by thread 'Thread-102'
> Stack trace:
>
>
> org.apache.commons.logging.impl.WeakHashtable.purge(WeakHashtable.java:323)
>
> org.apache.commons.logging.impl.WeakHashtable.rehash(WeakHashtable.java:312)
> java.util.Hashtable.put(Hashtable.java:414)
>
> org.apache.commons.logging.impl.WeakHashtable.put(WeakHashtable.java:242)
>
> org.apache.commons.logging.LogFactory.cacheFactory(LogFactory.java:1004)
> org.apache.commons.logging.LogFactory.getFactory(LogFactory.java:657)
> org.apache.commons.logging.LogFactory.getLog(LogFactory.java:685)
>
> org.springframework.web.context.ContextLoader.(ContextLoader.java:145)
>
> [deadlocked thread] Thread-102:
> --
> Thread 'Thread-102' is waiting to acquire lock
> 'org.apache.commons.logging.impl.
> WeakHashtable@1e02138' that is held by thread 'Thread-96'
> Stack trace:
>
> java.util.Hashtable.remove(Hashtable.java:437)
>
> org.apache.commons.logging.impl.WeakHashtable.purgeOne(WeakHashtable.java:338)
>
> org.apache.commons.logging.impl.WeakHashtable.put(WeakHashtable.java:238)
>
> org.apache.commons.logging.LogFactory.cacheFactory(LogFactory.java:1004)
> org.apache.commons.logging.LogFactory.getFactory(LogFactory.java:657)
> org.apache.commons.logging.LogFactory.getLog(LogFactory.java:685)
>
> org.springframework.web.context.ContextLoader.(ContextLoader.java:145)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (VFS-461) [FTP/FTPS] Cannot set SoTimeout and Encoding with system properties
[ https://issues.apache.org/jira/browse/VFS-461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joerg Schaible resolved VFS-461. Resolution: Fixed $ svn ci -m "ConfigBuilder does not consider system properties for the value of SoTimeout and Encoding." Sending core/src/main/java/org/apache/commons/vfs2/provider/ftp/FtpFileSystemConfigBuilder.java Sendingsrc/changes/changes.xml Transmitting file data .. Committed revision 1448645. > [FTP/FTPS] Cannot set SoTimeout and Encoding with system properties > --- > > Key: VFS-461 > URL: https://issues.apache.org/jira/browse/VFS-461 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Joerg Schaible >Assignee: Joerg Schaible >Priority: Trivial > Fix For: 2.1 > > > FtpFileSystemConfigBuilder does not consider system properties for the > configuration values of the SoTimeout and the Encoding. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VFS-460) commons-compress not optional
[ https://issues.apache.org/jira/browse/VFS-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13583215#comment-13583215 ] Gary Gregory commented on VFS-460: -- Hm. I wonder why they are not optional is the root POM. > commons-compress not optional > - > > Key: VFS-460 > URL: https://issues.apache.org/jira/browse/VFS-460 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Joerg Schaible > Fix For: 2.1 > > > commons-compress dependency is not declared as optional. On purpose or plain > oversight? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (VFS-462) [FTPS] Use enum instead of String for FtpsType
Joerg Schaible created VFS-462: -- Summary: [FTPS] Use enum instead of String for FtpsType Key: VFS-462 URL: https://issues.apache.org/jira/browse/VFS-462 Project: Commons VFS Issue Type: Bug Affects Versions: 2.0 Reporter: Joerg Schaible Assignee: Joerg Schaible Priority: Trivial Fix For: 2.1 The connection mode for FTPS is configured with a string. Actually the underlaying implementation uses a boolean to separate between "implicit" and "explicit" mode, therefore it is somewhat strange to introduce two string constants for this option and throw an exception (non-localized) if the provided configuration value does not match. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (VFS-462) [FTPS] Use enum instead of String for FtpsType
[ https://issues.apache.org/jira/browse/VFS-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joerg Schaible updated VFS-462: --- Issue Type: Improvement (was: Bug) > [FTPS] Use enum instead of String for FtpsType > -- > > Key: VFS-462 > URL: https://issues.apache.org/jira/browse/VFS-462 > Project: Commons VFS > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Joerg Schaible >Assignee: Joerg Schaible >Priority: Trivial > Fix For: 2.1 > > > The connection mode for FTPS is configured with a string. Actually the > underlaying implementation uses a boolean to separate between "implicit" and > "explicit" mode, therefore it is somewhat strange to introduce two string > constants for this option and throw an exception (non-localized) if the > provided configuration value does not match. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LOGGING-119) deadlock on re-registration of logger
[ https://issues.apache.org/jira/browse/LOGGING-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13583221#comment-13583221 ] Thomas Neidhart commented on LOGGING-119: - commons-logging was created and still targets for JDK 1.1. Map and WeakHashMap did not yet exist at the time, so there was a need for an own implementation of a WeakHashtable. It was decided to keep the compatibility settings as is for the 1.1.2 bugfix release, especially to keep binary compatibility. Changing the internal factories to a Map would break compatibility. What will happen after 1.1.2 is unclear. Either commons-logging will die, or we will modernize it and release a non-compatible version 2. > deadlock on re-registration of logger > - > > Key: LOGGING-119 > URL: https://issues.apache.org/jira/browse/LOGGING-119 > Project: Commons Logging > Issue Type: Bug >Affects Versions: 1.1.1 > Environment: Java 1.5, Windows >Reporter: Nitzan Niv > Fix For: 1.1.2 > > Attachments: BugDeadlock.java, Patch-WeakHashtable-1.1.1.txt > > > Reached a deadlock inside common-logging while concurrently re-deploying 2 > WARs. > In each WAR there is an attempt to get a logger: > private final Log logger = LogFactory.getLog(ContextLoader.class); > Thread dump: > [deadlocked thread] Thread-96: > - > Thread 'Thread-96' is waiting to acquire lock > 'java.lang.ref.ReferenceQueue@5266e0' that is held by thread 'Thread-102' > Stack trace: > > > org.apache.commons.logging.impl.WeakHashtable.purge(WeakHashtable.java:323) > > org.apache.commons.logging.impl.WeakHashtable.rehash(WeakHashtable.java:312) > java.util.Hashtable.put(Hashtable.java:414) > > org.apache.commons.logging.impl.WeakHashtable.put(WeakHashtable.java:242) > > org.apache.commons.logging.LogFactory.cacheFactory(LogFactory.java:1004) > org.apache.commons.logging.LogFactory.getFactory(LogFactory.java:657) > org.apache.commons.logging.LogFactory.getLog(LogFactory.java:685) > > org.springframework.web.context.ContextLoader.(ContextLoader.java:145) > > [deadlocked thread] Thread-102: > -- > Thread 'Thread-102' is waiting to acquire lock > 'org.apache.commons.logging.impl. > WeakHashtable@1e02138' that is held by thread 'Thread-96' > Stack trace: > > java.util.Hashtable.remove(Hashtable.java:437) > > org.apache.commons.logging.impl.WeakHashtable.purgeOne(WeakHashtable.java:338) > > org.apache.commons.logging.impl.WeakHashtable.put(WeakHashtable.java:238) > > org.apache.commons.logging.LogFactory.cacheFactory(LogFactory.java:1004) > org.apache.commons.logging.LogFactory.getFactory(LogFactory.java:657) > org.apache.commons.logging.LogFactory.getLog(LogFactory.java:685) > > org.springframework.web.context.ContextLoader.(ContextLoader.java:145) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (LOGGING-119) deadlock on re-registration of logger
[ https://issues.apache.org/jira/browse/LOGGING-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13583221#comment-13583221 ] Thomas Neidhart edited comment on LOGGING-119 at 2/21/13 2:32 PM: -- commons-logging was created and still targets for JDK 1.1. Map and WeakHashMap did not yet exist at the time, so there was a need for an own implementation of a WeakHashtable. It was decided to keep the compatibility settings as is for the 1.1.2 bugfix release, especially to keep binary compatibility. Changing the internal factories to a Map would break compatibility. What will happen after 1.1.2 is unclear. Either commons-logging will die, or we will modernize it and release a non binary compatible version 2. was (Author: tn): commons-logging was created and still targets for JDK 1.1. Map and WeakHashMap did not yet exist at the time, so there was a need for an own implementation of a WeakHashtable. It was decided to keep the compatibility settings as is for the 1.1.2 bugfix release, especially to keep binary compatibility. Changing the internal factories to a Map would break compatibility. What will happen after 1.1.2 is unclear. Either commons-logging will die, or we will modernize it and release a non-compatible version 2. > deadlock on re-registration of logger > - > > Key: LOGGING-119 > URL: https://issues.apache.org/jira/browse/LOGGING-119 > Project: Commons Logging > Issue Type: Bug >Affects Versions: 1.1.1 > Environment: Java 1.5, Windows >Reporter: Nitzan Niv > Fix For: 1.1.2 > > Attachments: BugDeadlock.java, Patch-WeakHashtable-1.1.1.txt > > > Reached a deadlock inside common-logging while concurrently re-deploying 2 > WARs. > In each WAR there is an attempt to get a logger: > private final Log logger = LogFactory.getLog(ContextLoader.class); > Thread dump: > [deadlocked thread] Thread-96: > - > Thread 'Thread-96' is waiting to acquire lock > 'java.lang.ref.ReferenceQueue@5266e0' that is held by thread 'Thread-102' > Stack trace: > > > org.apache.commons.logging.impl.WeakHashtable.purge(WeakHashtable.java:323) > > org.apache.commons.logging.impl.WeakHashtable.rehash(WeakHashtable.java:312) > java.util.Hashtable.put(Hashtable.java:414) > > org.apache.commons.logging.impl.WeakHashtable.put(WeakHashtable.java:242) > > org.apache.commons.logging.LogFactory.cacheFactory(LogFactory.java:1004) > org.apache.commons.logging.LogFactory.getFactory(LogFactory.java:657) > org.apache.commons.logging.LogFactory.getLog(LogFactory.java:685) > > org.springframework.web.context.ContextLoader.(ContextLoader.java:145) > > [deadlocked thread] Thread-102: > -- > Thread 'Thread-102' is waiting to acquire lock > 'org.apache.commons.logging.impl. > WeakHashtable@1e02138' that is held by thread 'Thread-96' > Stack trace: > > java.util.Hashtable.remove(Hashtable.java:437) > > org.apache.commons.logging.impl.WeakHashtable.purgeOne(WeakHashtable.java:338) > > org.apache.commons.logging.impl.WeakHashtable.put(WeakHashtable.java:238) > > org.apache.commons.logging.LogFactory.cacheFactory(LogFactory.java:1004) > org.apache.commons.logging.LogFactory.getFactory(LogFactory.java:657) > org.apache.commons.logging.LogFactory.getLog(LogFactory.java:685) > > org.springframework.web.context.ContextLoader.(ContextLoader.java:145) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VFS-460) commons-compress not optional
[ https://issues.apache.org/jira/browse/VFS-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13583226#comment-13583226 ] Joerg Schaible commented on VFS-460: ?? But they *are* optional, just not commons-compress. IMHO this was a plain oversight. > commons-compress not optional > - > > Key: VFS-460 > URL: https://issues.apache.org/jira/browse/VFS-460 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Joerg Schaible > Fix For: 2.1 > > > commons-compress dependency is not declared as optional. On purpose or plain > oversight? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (VFS-462) [FTPS] Use enum instead of String for FtpsType
[ https://issues.apache.org/jira/browse/VFS-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joerg Schaible resolved VFS-462. Resolution: Fixed Since the value type could not be changed without breaking backward compatibility, new getters and setters have been introduced along with the new enum. Old getter and setter have been decprecated. $ svn ci -m "Deprecate FtpsFileSystemConfigBuilder.setFtpsType and FtpsFileSystemConfigBuilder.getFtpsType in favor of FtpsFileSystemConfigBuilder.setFtpsMode and FtpsFileSystemConfigBuilder.getFtpsMode which use new enum FtpsMode instead (VFS-462)." Sending core/src/main/java/org/apache/commons/vfs2/provider/ftp/FtpFileSystemConfigBuilder.java Sending core/src/main/java/org/apache/commons/vfs2/provider/ftps/FtpsClientFactory.java Sending core/src/main/java/org/apache/commons/vfs2/provider/ftps/FtpsFileSystemConfigBuilder.java Adding core/src/main/java/org/apache/commons/vfs2/provider/ftps/FtpsMode.java Sending core/src/test/java/org/apache/commons/vfs2/provider/ftps/test/FtpsProviderExplicitTestCase.java Sending core/src/test/java/org/apache/commons/vfs2/provider/ftps/test/FtpsProviderImplicitTestCase_Disabled.java Sendingsrc/changes/changes.xml Transmitting file data ... Committed revision 1448668. > [FTPS] Use enum instead of String for FtpsType > -- > > Key: VFS-462 > URL: https://issues.apache.org/jira/browse/VFS-462 > Project: Commons VFS > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Joerg Schaible >Assignee: Joerg Schaible >Priority: Trivial > Fix For: 2.1 > > > The connection mode for FTPS is configured with a string. Actually the > underlaying implementation uses a boolean to separate between "implicit" and > "explicit" mode, therefore it is somewhat strange to introduce two string > constants for this option and throw an exception (non-localized) if the > provided configuration value does not match. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LOGGING-119) deadlock on re-registration of logger
[ https://issues.apache.org/jira/browse/LOGGING-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13583238#comment-13583238 ] Olivier Lamy (*$^¨%`£) commented on LOGGING-119: jdk 1.1 target ? really in 2013 ? > deadlock on re-registration of logger > - > > Key: LOGGING-119 > URL: https://issues.apache.org/jira/browse/LOGGING-119 > Project: Commons Logging > Issue Type: Bug >Affects Versions: 1.1.1 > Environment: Java 1.5, Windows >Reporter: Nitzan Niv > Fix For: 1.1.2 > > Attachments: BugDeadlock.java, Patch-WeakHashtable-1.1.1.txt > > > Reached a deadlock inside common-logging while concurrently re-deploying 2 > WARs. > In each WAR there is an attempt to get a logger: > private final Log logger = LogFactory.getLog(ContextLoader.class); > Thread dump: > [deadlocked thread] Thread-96: > - > Thread 'Thread-96' is waiting to acquire lock > 'java.lang.ref.ReferenceQueue@5266e0' that is held by thread 'Thread-102' > Stack trace: > > > org.apache.commons.logging.impl.WeakHashtable.purge(WeakHashtable.java:323) > > org.apache.commons.logging.impl.WeakHashtable.rehash(WeakHashtable.java:312) > java.util.Hashtable.put(Hashtable.java:414) > > org.apache.commons.logging.impl.WeakHashtable.put(WeakHashtable.java:242) > > org.apache.commons.logging.LogFactory.cacheFactory(LogFactory.java:1004) > org.apache.commons.logging.LogFactory.getFactory(LogFactory.java:657) > org.apache.commons.logging.LogFactory.getLog(LogFactory.java:685) > > org.springframework.web.context.ContextLoader.(ContextLoader.java:145) > > [deadlocked thread] Thread-102: > -- > Thread 'Thread-102' is waiting to acquire lock > 'org.apache.commons.logging.impl. > WeakHashtable@1e02138' that is held by thread 'Thread-96' > Stack trace: > > java.util.Hashtable.remove(Hashtable.java:437) > > org.apache.commons.logging.impl.WeakHashtable.purgeOne(WeakHashtable.java:338) > > org.apache.commons.logging.impl.WeakHashtable.put(WeakHashtable.java:238) > > org.apache.commons.logging.LogFactory.cacheFactory(LogFactory.java:1004) > org.apache.commons.logging.LogFactory.getFactory(LogFactory.java:657) > org.apache.commons.logging.LogFactory.getLog(LogFactory.java:685) > > org.springframework.web.context.ContextLoader.(ContextLoader.java:145) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VFS-460) commons-compress not optional
[ https://issues.apache.org/jira/browse/VFS-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13583244#comment-13583244 ] Gary Gregory commented on VFS-460: -- OK. > commons-compress not optional > - > > Key: VFS-460 > URL: https://issues.apache.org/jira/browse/VFS-460 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Joerg Schaible > Fix For: 2.1 > > > commons-compress dependency is not declared as optional. On purpose or plain > oversight? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LOGGING-119) deadlock on re-registration of logger
[ https://issues.apache.org/jira/browse/LOGGING-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13583246#comment-13583246 ] Gary Gregory commented on LOGGING-119: -- and it's February 2013! ;) I think we can bump the target to 1.4 without controversy. The super conservative route would be to # release 1.1.2 as is, no platform changes. # update the platform requirement to whatever we agree on for 1.2, Java 1.4, 5, 6, or 7. > deadlock on re-registration of logger > - > > Key: LOGGING-119 > URL: https://issues.apache.org/jira/browse/LOGGING-119 > Project: Commons Logging > Issue Type: Bug >Affects Versions: 1.1.1 > Environment: Java 1.5, Windows >Reporter: Nitzan Niv > Fix For: 1.1.2 > > Attachments: BugDeadlock.java, Patch-WeakHashtable-1.1.1.txt > > > Reached a deadlock inside common-logging while concurrently re-deploying 2 > WARs. > In each WAR there is an attempt to get a logger: > private final Log logger = LogFactory.getLog(ContextLoader.class); > Thread dump: > [deadlocked thread] Thread-96: > - > Thread 'Thread-96' is waiting to acquire lock > 'java.lang.ref.ReferenceQueue@5266e0' that is held by thread 'Thread-102' > Stack trace: > > > org.apache.commons.logging.impl.WeakHashtable.purge(WeakHashtable.java:323) > > org.apache.commons.logging.impl.WeakHashtable.rehash(WeakHashtable.java:312) > java.util.Hashtable.put(Hashtable.java:414) > > org.apache.commons.logging.impl.WeakHashtable.put(WeakHashtable.java:242) > > org.apache.commons.logging.LogFactory.cacheFactory(LogFactory.java:1004) > org.apache.commons.logging.LogFactory.getFactory(LogFactory.java:657) > org.apache.commons.logging.LogFactory.getLog(LogFactory.java:685) > > org.springframework.web.context.ContextLoader.(ContextLoader.java:145) > > [deadlocked thread] Thread-102: > -- > Thread 'Thread-102' is waiting to acquire lock > 'org.apache.commons.logging.impl. > WeakHashtable@1e02138' that is held by thread 'Thread-96' > Stack trace: > > java.util.Hashtable.remove(Hashtable.java:437) > > org.apache.commons.logging.impl.WeakHashtable.purgeOne(WeakHashtable.java:338) > > org.apache.commons.logging.impl.WeakHashtable.put(WeakHashtable.java:238) > > org.apache.commons.logging.LogFactory.cacheFactory(LogFactory.java:1004) > org.apache.commons.logging.LogFactory.getFactory(LogFactory.java:657) > org.apache.commons.logging.LogFactory.getLog(LogFactory.java:685) > > org.springframework.web.context.ContextLoader.(ContextLoader.java:145) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (VFS-463) Support system propeties for enum-based configuration values
Joerg Schaible created VFS-463: -- Summary: Support system propeties for enum-based configuration values Key: VFS-463 URL: https://issues.apache.org/jira/browse/VFS-463 Project: Commons VFS Issue Type: Improvement Affects Versions: 2.0 Reporter: Joerg Schaible Priority: Trivial Fix For: 2.1 All configuration values that are of a primitive type (or their boxed counterpart) or String can also be set with a system property. The same should be possible for enum-based values. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-917) More distance measurements are needed in o.a.c.m.stat.clustering.
[
https://issues.apache.org/jira/browse/MATH-917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13583284#comment-13583284
]
Thomas Neidhart commented on MATH-917:
--
Sorry, it did take me some time to review this contributions.
The existing API for clustering algorithms is not really flexible. The actual
distance calculation is provided / performed in the data point class.
With java and its primitive type system, it is difficult to come up with a
generic version, so I think a Distance interface which targets double would be
a good start and sufficient for most of the use-cases:
{noformat}
public interface Distance {
double distance(DataPoint a, DataPoint b)
}
{noformat}
The DataPoint class does not exist yet, we have only the Clusterable interface,
but this is not very useful imho.
The actual Distance implementation may then be provided as input to the
clustering algorithm.
But this is only one aspect, as the whole clustering package should be
refactored:
* have a base ClusteringAlgorithm interface
* pluggable Distance measures
* flexible DataPoint implementation
* flexible Cluster data structure for result (hierarchical vs. flat, centroid
based vs. other)
> More distance measurements are needed in o.a.c.m.stat.clustering.
> -
>
> Key: MATH-917
> URL: https://issues.apache.org/jira/browse/MATH-917
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Reid Hochstedler
> Fix For: 3.2
>
>
> Currently only Euclidean distance is used for distance measurement, it would
> be easy to quickly add Manhattan and Chebyshev distance among others.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (EMAIL-124) Header values are folded twice and thus creating defective emails
[ https://issues.apache.org/jira/browse/EMAIL-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13583287#comment-13583287 ] Thomas Neidhart commented on EMAIL-124: --- Can you check with the latest trunk version if the problem is solved for you? I will then start a release tomorrow. Thanks, Thomas > Header values are folded twice and thus creating defective emails > - > > Key: EMAIL-124 > URL: https://issues.apache.org/jira/browse/EMAIL-124 > Project: Commons Email > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Stefan Schueffler >Priority: Blocker > Fix For: 1.3.1 > > Original Estimate: 5m > Remaining Estimate: 5m > > With EMAIL-98, header values now are folded by commons-email. > Unfortunately, they are folded twice: once in "Mail.addHeader" or > "Mail.setHeaders", and once again in "Mail.buildMimeMessage()" while > iterating over the headers. > This results (in our test cases) in corrupted mail header lines having > additional blank lines between the first and second line of a folded value - > and thus ends in corrupted mails (as all headers after the first blank line > are threatened as mail-body-content). > As this renders "additional headers" useless in commons-mail and corrupts > every mail having additionl headers with longer-than-folding-size values, i > set the priority to blocker. > The fix seems to be easy: just fold either in addHeader and setHeaders, or in > buildMimeMessage (but not in both). > My preferred solution would be to fold in buildMimeMessage, and to store the > values "as-is" in addHeader and setHeaders so one is able to work with the > plain values (if neccessary) until the mail is actually build and send. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (VFS-463) Support system propeties for enum-based configuration values
[ https://issues.apache.org/jira/browse/VFS-463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joerg Schaible resolved VFS-463. Resolution: Fixed $ svn ci -m "FileSytemConfigBuilder supports system properties for the value of enum-based configuration entries (VFS-463)." Sending core/src/main/java/org/apache/commons/vfs2/FileSystemConfigBuilder.java Sending core/src/main/java/org/apache/commons/vfs2/provider/ftp/FtpFileSystemConfigBuilder.java Sending core/src/main/java/org/apache/commons/vfs2/provider/ftps/FtpsFileSystemConfigBuilder.java Sending core/src/main/java/org/apache/commons/vfs2/provider/sftp/SftpFileSystemConfigBuilder.java Sendingsrc/changes/changes.xml Transmitting file data . Committed revision 1448689. > Support system propeties for enum-based configuration values > > > Key: VFS-463 > URL: https://issues.apache.org/jira/browse/VFS-463 > Project: Commons VFS > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Joerg Schaible >Priority: Trivial > Fix For: 2.1 > > > All configuration values that are of a primitive type (or their boxed > counterpart) or String can also be set with a system property. The same > should be possible for enum-based values. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (VFS-186) Make SFTP file system multi-thread aware
[ https://issues.apache.org/jira/browse/VFS-186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joerg Schaible updated VFS-186: --- Summary: Make SFTP file system multi-thread aware (was: Make SFTP file system mutli-thread aware) > Make SFTP file system multi-thread aware > > > Key: VFS-186 > URL: https://issues.apache.org/jira/browse/VFS-186 > Project: Commons VFS > Issue Type: Improvement >Affects Versions: 1.1 >Reporter: Jerome Lacoste > Attachments: VFS-186.diff > > > We wrote a simple unit test to stress test commons-vfs sftp implementation. > We used multiple-threads. > We ran into various issues, some in jsch 0.1.36, some in commons-vfs. After > applying the following patch (in combination with those for jsch), > commons-vfs became much more reliable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LOGGING-119) deadlock on re-registration of logger
[ https://issues.apache.org/jira/browse/LOGGING-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13583314#comment-13583314 ] Thomas Neidhart commented on LOGGING-119: - Well, for 1.1.2 it does not make much of a difference if we change the target. We have to stick to Hashtables for now to keep binary compatibility. The problem here should be solved, and for future versions (1.2?, 2.0) we will surely use existing stuff like WeakHashMap. > deadlock on re-registration of logger > - > > Key: LOGGING-119 > URL: https://issues.apache.org/jira/browse/LOGGING-119 > Project: Commons Logging > Issue Type: Bug >Affects Versions: 1.1.1 > Environment: Java 1.5, Windows >Reporter: Nitzan Niv > Fix For: 1.1.2 > > Attachments: BugDeadlock.java, Patch-WeakHashtable-1.1.1.txt > > > Reached a deadlock inside common-logging while concurrently re-deploying 2 > WARs. > In each WAR there is an attempt to get a logger: > private final Log logger = LogFactory.getLog(ContextLoader.class); > Thread dump: > [deadlocked thread] Thread-96: > - > Thread 'Thread-96' is waiting to acquire lock > 'java.lang.ref.ReferenceQueue@5266e0' that is held by thread 'Thread-102' > Stack trace: > > > org.apache.commons.logging.impl.WeakHashtable.purge(WeakHashtable.java:323) > > org.apache.commons.logging.impl.WeakHashtable.rehash(WeakHashtable.java:312) > java.util.Hashtable.put(Hashtable.java:414) > > org.apache.commons.logging.impl.WeakHashtable.put(WeakHashtable.java:242) > > org.apache.commons.logging.LogFactory.cacheFactory(LogFactory.java:1004) > org.apache.commons.logging.LogFactory.getFactory(LogFactory.java:657) > org.apache.commons.logging.LogFactory.getLog(LogFactory.java:685) > > org.springframework.web.context.ContextLoader.(ContextLoader.java:145) > > [deadlocked thread] Thread-102: > -- > Thread 'Thread-102' is waiting to acquire lock > 'org.apache.commons.logging.impl. > WeakHashtable@1e02138' that is held by thread 'Thread-96' > Stack trace: > > java.util.Hashtable.remove(Hashtable.java:437) > > org.apache.commons.logging.impl.WeakHashtable.purgeOne(WeakHashtable.java:338) > > org.apache.commons.logging.impl.WeakHashtable.put(WeakHashtable.java:238) > > org.apache.commons.logging.LogFactory.cacheFactory(LogFactory.java:1004) > org.apache.commons.logging.LogFactory.getFactory(LogFactory.java:657) > org.apache.commons.logging.LogFactory.getLog(LogFactory.java:685) > > org.springframework.web.context.ContextLoader.(ContextLoader.java:145) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (VFS-451) Authentication fails using private key
[ https://issues.apache.org/jira/browse/VFS-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joerg Schaible reopened VFS-451: IMHO this change is actually wrong. The password parameter is typically used for authentication if the password has to be sent as part of the URL. Now it is abused as passphrase for an identity file. We face with this solution two problems: # the password is still used in the URL (!!!) # the generation of the SftpClient fails always if you have multiple identities and they do not all share the same passphrase Therefore we should actually rollback this change and implement a solution as proposed in VFS-283 and reuse that mechanism for FTPS. > Authentication fails using private key > -- > > Key: VFS-451 > URL: https://issues.apache.org/jira/browse/VFS-451 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.0 > Environment: windows as client > linux as ssh server >Reporter: Marco Ronchi >Assignee: Gary Gregory > Fix For: 2.1 > > Attachments: SftpClientFactory.java.patch, SimpleTest.java, > vfs-patch-2.txt > > > Cannot connect to a ssh server with my private key. > I believe the issue is due to an JSCH bug. > Using the following lines: > session.setPassword(pass); > jsch.addIdentity(identityfile); > instead of > jsch.addIdentity(privateKeyFilePath,password); > authentication fails. > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (BEANUTILS-421) NullPointerException in BeanUtilsBean.setProperty
[ https://issues.apache.org/jira/browse/BEANUTILS-421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13583395#comment-13583395 ] Benedikt Ritter commented on BEANUTILS-421: --- Hi Maxim, can you provide a svn patch including a JUnit test and the fix against trunk? Regards, Benedikt > NullPointerException in BeanUtilsBean.setProperty > - > > Key: BEANUTILS-421 > URL: https://issues.apache.org/jira/browse/BEANUTILS-421 > Project: Commons BeanUtils > Issue Type: Bug >Affects Versions: 1.8.3 >Reporter: Maxim Kramarenko >Priority: Blocker > > I got the following exception on some servers: >javax.servlet.ServletException: BeanUtils.populate > at org.apache.struts.util.RequestUtils.populate(RequestUtils.java:475) > at > org.apache.struts.chain.commands.servlet.PopulateActionForm.populate(PopulateActionForm.java:50) > at > org.apache.struts.chain.commands.AbstractPopulateActionForm.execute(AbstractPopulateActionForm.java:60) > at > org.apache.struts.chain.commands.ActionCommandBase.execute(ActionCommandBase.java:51) > at org.apache.commons.chain.impl.ChainBase.execute(ChainBase.java:191) > at > org.apache.commons.chain.generic.LookupCommand.execute(LookupCommand.java:305) > at org.apache.commons.chain.impl.ChainBase.execute(ChainBase.java:191) > at > org.apache.struts.chain.ComposableRequestProcessor.process(ComposableRequestProcessor.java:283) > at > org.apache.struts.action.ActionServlet.process(ActionServlet.java:1913) > at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:462) > Caused by: java.lang.NullPointerException > at > org.apache.commons.beanutils.BeanUtilsBean.setProperty(BeanUtilsBean.java:982) > at > org.apache.commons.beanutils.BeanUtilsBean.populate(BeanUtilsBean.java:830) > at org.apache.commons.beanutils.BeanUtils.populate(BeanUtils.java:433) > at org.apache.struts.util.RequestUtils.populate(RequestUtils.java:473) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (BEANUTILS-421) NullPointerException in BeanUtilsBean.setProperty
[ https://issues.apache.org/jira/browse/BEANUTILS-421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated BEANUTILS-421: -- Fix Version/s: 1.8.4 > NullPointerException in BeanUtilsBean.setProperty > - > > Key: BEANUTILS-421 > URL: https://issues.apache.org/jira/browse/BEANUTILS-421 > Project: Commons BeanUtils > Issue Type: Bug >Affects Versions: 1.8.3 >Reporter: Maxim Kramarenko >Assignee: Benedikt Ritter >Priority: Blocker > Fix For: 1.8.4 > > > I got the following exception on some servers: >javax.servlet.ServletException: BeanUtils.populate > at org.apache.struts.util.RequestUtils.populate(RequestUtils.java:475) > at > org.apache.struts.chain.commands.servlet.PopulateActionForm.populate(PopulateActionForm.java:50) > at > org.apache.struts.chain.commands.AbstractPopulateActionForm.execute(AbstractPopulateActionForm.java:60) > at > org.apache.struts.chain.commands.ActionCommandBase.execute(ActionCommandBase.java:51) > at org.apache.commons.chain.impl.ChainBase.execute(ChainBase.java:191) > at > org.apache.commons.chain.generic.LookupCommand.execute(LookupCommand.java:305) > at org.apache.commons.chain.impl.ChainBase.execute(ChainBase.java:191) > at > org.apache.struts.chain.ComposableRequestProcessor.process(ComposableRequestProcessor.java:283) > at > org.apache.struts.action.ActionServlet.process(ActionServlet.java:1913) > at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:462) > Caused by: java.lang.NullPointerException > at > org.apache.commons.beanutils.BeanUtilsBean.setProperty(BeanUtilsBean.java:982) > at > org.apache.commons.beanutils.BeanUtilsBean.populate(BeanUtilsBean.java:830) > at org.apache.commons.beanutils.BeanUtils.populate(BeanUtils.java:433) > at org.apache.struts.util.RequestUtils.populate(RequestUtils.java:473) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (BEANUTILS-421) NullPointerException in BeanUtilsBean.setProperty
[ https://issues.apache.org/jira/browse/BEANUTILS-421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated BEANUTILS-421: -- Component/s: Bean / Property Utils > NullPointerException in BeanUtilsBean.setProperty > - > > Key: BEANUTILS-421 > URL: https://issues.apache.org/jira/browse/BEANUTILS-421 > Project: Commons BeanUtils > Issue Type: Bug > Components: Bean / Property Utils >Affects Versions: 1.8.3 >Reporter: Maxim Kramarenko >Assignee: Benedikt Ritter >Priority: Blocker > Fix For: 1.8.4 > > > I got the following exception on some servers: >javax.servlet.ServletException: BeanUtils.populate > at org.apache.struts.util.RequestUtils.populate(RequestUtils.java:475) > at > org.apache.struts.chain.commands.servlet.PopulateActionForm.populate(PopulateActionForm.java:50) > at > org.apache.struts.chain.commands.AbstractPopulateActionForm.execute(AbstractPopulateActionForm.java:60) > at > org.apache.struts.chain.commands.ActionCommandBase.execute(ActionCommandBase.java:51) > at org.apache.commons.chain.impl.ChainBase.execute(ChainBase.java:191) > at > org.apache.commons.chain.generic.LookupCommand.execute(LookupCommand.java:305) > at org.apache.commons.chain.impl.ChainBase.execute(ChainBase.java:191) > at > org.apache.struts.chain.ComposableRequestProcessor.process(ComposableRequestProcessor.java:283) > at > org.apache.struts.action.ActionServlet.process(ActionServlet.java:1913) > at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:462) > Caused by: java.lang.NullPointerException > at > org.apache.commons.beanutils.BeanUtilsBean.setProperty(BeanUtilsBean.java:982) > at > org.apache.commons.beanutils.BeanUtilsBean.populate(BeanUtilsBean.java:830) > at org.apache.commons.beanutils.BeanUtils.populate(BeanUtils.java:433) > at org.apache.struts.util.RequestUtils.populate(RequestUtils.java:473) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LOGGING-144) LogFactory/LogFactoryImpl ingore Throwable
[
https://issues.apache.org/jira/browse/LOGGING-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13583399#comment-13583399
]
Sebb commented on LOGGING-144:
--
The patch changes the code to how it should have been written originally.
However, it means that the code may potentially throw some additional unchecked
exceptions, whereas previously the code would log them and continue.
If that is not acceptable, then the alternative approach is to use a method
such as
org.apache.tomcat.util.ExceptionUtils.handleThrowable(Throwable t) [1]
For example:
{code}
} catch (Throwable t) {
handleThrowable(t); // may not return
logDiagnostic(...);
}
{code}
[1]
http://svn.apache.org/repos/asf/tomcat/trunk/java/org/apache/tomcat/util/ExceptionUtils.java
> LogFactory/LogFactoryImpl ingore Throwable
> --
>
> Key: LOGGING-144
> URL: https://issues.apache.org/jira/browse/LOGGING-144
> Project: Commons Logging
> Issue Type: Bug
>Affects Versions: 1.1.1
>Reporter: Sebb
> Attachments: LOGGING-144.patch
>
>
> The code in LogFactory/LogFactoryImpl catches and ignores Throwable in
> several places.
> This is a bad idea, as some Throwables (e.g. ThreadDeath) should never be
> ignored.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (BEANUTILS-410) No bean defined exception with mapped properties
[
https://issues.apache.org/jira/browse/BEANUTILS-410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13583402#comment-13583402
]
Benedikt Ritter commented on BEANUTILS-410:
---
Hi Daniel,
would you mind to create a svn patch that contains a JUnit test, that shows
this bug?
TIA!
Benedikt
> No bean defined exception with mapped properties
>
>
> Key: BEANUTILS-410
> URL: https://issues.apache.org/jira/browse/BEANUTILS-410
> Project: Commons BeanUtils
> Issue Type: Bug
> Components: Bean / Property Utils
>Affects Versions: 1.8.3
> Environment: All Operating Systems
>Reporter: DANIEL BRASIL
>Assignee: Benedikt Ritter
>Priority: Blocker
> Labels: bug
> Original Estimate: 96h
> Remaining Estimate: 96h
>
> The following code throws an exception. The same code does not throw
> exception at 1.7.0 version.
> The code tries to set property "_new_value" on bean "teste(abc)". It's not
> the correct behavior since the property accessor notation is ".".
> {Code}
> import java.util.HashMap;
> import java.util.Map;
> public class MappedBean {
> public Map teste = new HashMap();
> public String getTeste(String key) {
> return this.teste.get(key);
> }
> public void setTeste(String key, String value) {
> this.teste.put(key, value);
> }
> }
> {Code}
> {Code}
> MappedBean testeBean = new MappedBean();
> Map properties = new HashMap();
> properties.put("teste(abc)_new_value", "1234");
> BeanUtils.populate(testeBean, properties);
> {Code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (BEANUTILS-410) No bean defined exception with mapped properties
[
https://issues.apache.org/jira/browse/BEANUTILS-410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter updated BEANUTILS-410:
--
Fix Version/s: 1.8.4
> No bean defined exception with mapped properties
>
>
> Key: BEANUTILS-410
> URL: https://issues.apache.org/jira/browse/BEANUTILS-410
> Project: Commons BeanUtils
> Issue Type: Bug
> Components: Bean / Property Utils
>Affects Versions: 1.8.3
> Environment: All Operating Systems
>Reporter: DANIEL BRASIL
>Assignee: Benedikt Ritter
>Priority: Blocker
> Labels: bug
> Fix For: 1.8.4
>
> Original Estimate: 96h
> Remaining Estimate: 96h
>
> The following code throws an exception. The same code does not throw
> exception at 1.7.0 version.
> The code tries to set property "_new_value" on bean "teste(abc)". It's not
> the correct behavior since the property accessor notation is ".".
> {Code}
> import java.util.HashMap;
> import java.util.Map;
> public class MappedBean {
> public Map teste = new HashMap();
> public String getTeste(String key) {
> return this.teste.get(key);
> }
> public void setTeste(String key, String value) {
> this.teste.put(key, value);
> }
> }
> {Code}
> {Code}
> MappedBean testeBean = new MappedBean();
> Map properties = new HashMap();
> properties.put("teste(abc)_new_value", "1234");
> BeanUtils.populate(testeBean, properties);
> {Code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LOGGING-144) LogFactory/LogFactoryImpl ingore Throwable
[ https://issues.apache.org/jira/browse/LOGGING-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13583415#comment-13583415 ] Thomas Neidhart commented on LOGGING-144: - Thanks for the pointer, this looks cleaner compared to my patch. Although, if I understand it correctly, this will also throw additional unchecked exceptions (ThreadDeath & VirtualMachineError) that where swallowed and logged before? > LogFactory/LogFactoryImpl ingore Throwable > -- > > Key: LOGGING-144 > URL: https://issues.apache.org/jira/browse/LOGGING-144 > Project: Commons Logging > Issue Type: Bug >Affects Versions: 1.1.1 >Reporter: Sebb > Attachments: LOGGING-144.patch > > > The code in LogFactory/LogFactoryImpl catches and ignores Throwable in > several places. > This is a bad idea, as some Throwables (e.g. ThreadDeath) should never be > ignored. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (BEANUTILS-421) NullPointerException in BeanUtilsBean.setProperty
[ https://issues.apache.org/jira/browse/BEANUTILS-421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13583467#comment-13583467 ] Maxim Kramarenko commented on BEANUTILS-421: No, I cannot - just fixed it locally and have no patch file or test case. > NullPointerException in BeanUtilsBean.setProperty > - > > Key: BEANUTILS-421 > URL: https://issues.apache.org/jira/browse/BEANUTILS-421 > Project: Commons BeanUtils > Issue Type: Bug > Components: Bean / Property Utils >Affects Versions: 1.8.3 >Reporter: Maxim Kramarenko >Assignee: Benedikt Ritter >Priority: Blocker > Fix For: 1.8.4 > > > I got the following exception on some servers: >javax.servlet.ServletException: BeanUtils.populate > at org.apache.struts.util.RequestUtils.populate(RequestUtils.java:475) > at > org.apache.struts.chain.commands.servlet.PopulateActionForm.populate(PopulateActionForm.java:50) > at > org.apache.struts.chain.commands.AbstractPopulateActionForm.execute(AbstractPopulateActionForm.java:60) > at > org.apache.struts.chain.commands.ActionCommandBase.execute(ActionCommandBase.java:51) > at org.apache.commons.chain.impl.ChainBase.execute(ChainBase.java:191) > at > org.apache.commons.chain.generic.LookupCommand.execute(LookupCommand.java:305) > at org.apache.commons.chain.impl.ChainBase.execute(ChainBase.java:191) > at > org.apache.struts.chain.ComposableRequestProcessor.process(ComposableRequestProcessor.java:283) > at > org.apache.struts.action.ActionServlet.process(ActionServlet.java:1913) > at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:462) > Caused by: java.lang.NullPointerException > at > org.apache.commons.beanutils.BeanUtilsBean.setProperty(BeanUtilsBean.java:982) > at > org.apache.commons.beanutils.BeanUtilsBean.populate(BeanUtilsBean.java:830) > at org.apache.commons.beanutils.BeanUtils.populate(BeanUtils.java:433) > at org.apache.struts.util.RequestUtils.populate(RequestUtils.java:473) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-740) Some "FastMath" functions are slow
[ https://issues.apache.org/jira/browse/MATH-740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13583475#comment-13583475 ] Jeff Hain commented on MATH-740: FastMath (of apache, and of jafama/jodk) methods can actually be (multiple times) slower than Math ones when not JIT-optimized (run with -Xint to force interpreted calls). For jafama/jodk FastMath, which I saw you were considering putting into apache libs (.../apache_commons_math/slides/183/1600_Thomas.pdf), there are two more causes of slowness: - caches-misses on look-up tables - look-up tables initialization overhead (on class load) That said, once the initialization is done, if methods are not called a lot their slowness should usually not be a problem, and if they are, then they should hopefully be JIT-optimized with look-up tables in some CPU cache. In jafama/jodk look-up tables are enabled by default (more precisely, non-delegating to Math is enabled by default), but for a library as heavily used as apache commons math, I would tend to be conservative, and disable use of look-up tables by default to avoid surprising people with the initialization overhead (which on my computer can be as low as 100ms with Java 5, but gets worse with every new milestone of Java, up to 400ms with Java 8). But maybe people don't expect Java to ever start fast, in which case it might not be a problem ;) In latest jafama version (V2, from yesterday), I upgraded bench class, such as it's now easy to bench methods with values in various ranges. If I find out how I can do it, I'll upload it, stripped to match apache FastMath methods (3.1.1), so you can run it yourself, as well as the ouput of a run with -Xint. > Some "FastMath" functions are slow > -- > > Key: MATH-740 > URL: https://issues.apache.org/jira/browse/MATH-740 > Project: Commons Math > Issue Type: Wish >Reporter: Gilles >Priority: Minor > Fix For: 3.2 > > > From the two benchmarks we currently have in "FastMathTestPerfomance", we > have that the following functions are much slower in "FastMath" than in > either "Math" or "StrictMath" (the performance *loss*, for each of the > benchmarks, is given in parentheses): > * log10 (46%, 36%) > * log1p (68%, 112%) > * tan (11%, 61%) > * atan (26%, 125%) > * atan2 (44%, 40%) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LOGGING-144) LogFactory/LogFactoryImpl ingore Throwable
[ https://issues.apache.org/jira/browse/LOGGING-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13583496#comment-13583496 ] Sebb commented on LOGGING-144: -- bq. this will also throw additional unchecked exceptions (ThreadDeath & VirtualMachineError) that where swallowed and logged before? Well, yes, but those exceptions should never+ have been swallowed. > LogFactory/LogFactoryImpl ingore Throwable > -- > > Key: LOGGING-144 > URL: https://issues.apache.org/jira/browse/LOGGING-144 > Project: Commons Logging > Issue Type: Bug >Affects Versions: 1.1.1 >Reporter: Sebb > Attachments: LOGGING-144.patch > > > The code in LogFactory/LogFactoryImpl catches and ignores Throwable in > several places. > This is a bad idea, as some Throwables (e.g. ThreadDeath) should never be > ignored. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (LOGGING-144) LogFactory/LogFactoryImpl ingore Throwable
[ https://issues.apache.org/jira/browse/LOGGING-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13583496#comment-13583496 ] Sebb edited comment on LOGGING-144 at 2/21/13 8:00 PM: --- bq. this will also throw additional unchecked exceptions (ThreadDeath & VirtualMachineError) that where swallowed and logged before? Well, yes, but those exceptions should never have been swallowed. was (Author: s...@apache.org): bq. this will also throw additional unchecked exceptions (ThreadDeath & VirtualMachineError) that where swallowed and logged before? Well, yes, but those exceptions should never+ have been swallowed. > LogFactory/LogFactoryImpl ingore Throwable > -- > > Key: LOGGING-144 > URL: https://issues.apache.org/jira/browse/LOGGING-144 > Project: Commons Logging > Issue Type: Bug >Affects Versions: 1.1.1 >Reporter: Sebb > Attachments: LOGGING-144.patch > > > The code in LogFactory/LogFactoryImpl catches and ignores Throwable in > several places. > This is a bad idea, as some Throwables (e.g. ThreadDeath) should never be > ignored. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (EXEC-54) Problem with argument containing spaces
[
https://issues.apache.org/jira/browse/EXEC-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13583499#comment-13583499
]
DHadka commented on EXEC-54:
I'm running into a similar issue as above. In my case, I want to pass a folder
on the command line, such as C:\Documents and Settings\user\folder\. So I call
command.addArgument("C:\\Documents and Settings\\user\\folder\\"). Commons
Exec then adds the quotes around the argument. But on Windows, the trailing \
in the path escapes the quote, which then is passed as part of the argument.
In this case, the program receives the argument as: C:\Documents and
Settings\users\folder", with the quote as part of the argument. This creates a
subtle and hard to track error condition.
Consider these cases:
C:\NoSpace\in\path - Works correctly
C:\NoSpace\in\path\ - Works correctly (no quotes are added since no spaces in
path)
C:/NoSpace/in/path - Works correctly
C:/NoSpace/in/path/ - Works correctly
C:\With Space\in\path - Works correctly
C:\With Space\in\path\ - Fails due to this bug
C:/With Space/in/path - Works correctly
C:/With Space/in/path/ - Works correctly
> Problem with argument containing spaces
> ---
>
> Key: EXEC-54
> URL: https://issues.apache.org/jira/browse/EXEC-54
> Project: Commons Exec
> Issue Type: Bug
>Affects Versions: 1.1
> Environment: Mac OsX 10.6.6, JVM 1.6.0
>Reporter: Jeremias Rößler
>Assignee: Siegfried Goeschl
> Labels: arguments, quotes, spaces
>
> I am new to Commons Exec, so this could also be an error in usage, but...
> When I use the {{CommandLine}} class to add a argument that contains spaces,
> some quotes are added and are then part of the argument that is given.
> For example: When I call {{java "what version"}} I get
> {{java.lang.NoClassDefFoundError: what version}}, and when I call {{java
> "\"what version\""}} (which contains escaped quotes, that are part of the
> command line argument itself), I get {{java.lang.NoClassDefFoundError: "what
> version"}}.
> So the following test fails, because as you can see in the last line, Apache
> Exec is producing the latter version where it should have produced the first
> version:
> {code:java}
> @Test
> public void testArgumentQuoting() throws Exception {
> String argument = "what version";
> DefaultExecutor executor = new DefaultExecutor();
> DefaultExecuteResultHandler resultHandler = new
> DefaultExecuteResultHandler();
> ByteArrayOutputStream out = new ByteArrayOutputStream();
> PumpStreamHandler streamHandler = new PumpStreamHandler(out,
> out);
> executor.setStreamHandler(streamHandler);
> CommandLine cmdLine = new CommandLine("java");
> cmdLine.addArgument(argument);
> executor.execute(cmdLine, resultHandler);
> resultHandler.waitFor();
> String resultPattern = "Exception in thread \"main\"
> java\\.lang\\.NoClassDefFoundError: ([\\w \"]+)";
> Pattern pattern = Pattern.compile(resultPattern);
> Matcher matcher = pattern.matcher(out.toString());
> Assert.assertTrue(matcher.find());
> // Note: Result should be and NOT <"what
> version">!
> Assert.assertEquals(argument, matcher.group(1));
> }
> {code}
> Note that the same test passes if the space is removed from the argument.
> Please also note, that I am not trying to start an external Java process, but
> this is merely an example that I assume will work on every developers machine.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (EXEC-54) Problem with argument containing spaces
[
https://issues.apache.org/jira/browse/EXEC-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13583499#comment-13583499
]
DHadka edited comment on EXEC-54 at 2/21/13 8:05 PM:
-
I'm running into a similar issue as above. In my case, I want to pass a folder
on the command line, such as {{C:\Documents and Settings\user\folder\}}. So I
call {{command.addArgument("C:\\Documents and Settings\\user\\folder\\")}}.
Commons Exec then adds the quotes around the argument. But on Windows, the
trailing \ in the path escapes the quote, which then is passed as part of the
argument. In this case, the program receives the argument as: {{C:\Documents
and Settings\users\folder"}}, with the quote as part of the argument. This
creates a subtle and hard to track error condition.
Consider these cases:
C:\NoSpace\in\path - Works correctly
C:\NoSpace\in\path\ - Works correctly (no quotes are added since no spaces in
path)
C:/NoSpace/in/path - Works correctly
C:/NoSpace/in/path/ - Works correctly
C:\With Space\in\path - Works correctly
C:\With Space\in\path\ - Fails due to this bug
C:/With Space/in/path - Works correctly
C:/With Space/in/path/ - Works correctly
was (Author: dhadka):
I'm running into a similar issue as above. In my case, I want to pass a
folder on the command line, such as C:\Documents and Settings\user\folder\. So
I call command.addArgument("C:\\Documents and Settings\\user\\folder\\").
Commons Exec then adds the quotes around the argument. But on Windows, the
trailing \ in the path escapes the quote, which then is passed as part of the
argument. In this case, the program receives the argument as: C:\Documents and
Settings\users\folder", with the quote as part of the argument. This creates a
subtle and hard to track error condition.
Consider these cases:
C:\NoSpace\in\path - Works correctly
C:\NoSpace\in\path\ - Works correctly (no quotes are added since no spaces in
path)
C:/NoSpace/in/path - Works correctly
C:/NoSpace/in/path/ - Works correctly
C:\With Space\in\path - Works correctly
C:\With Space\in\path\ - Fails due to this bug
C:/With Space/in/path - Works correctly
C:/With Space/in/path/ - Works correctly
> Problem with argument containing spaces
> ---
>
> Key: EXEC-54
> URL: https://issues.apache.org/jira/browse/EXEC-54
> Project: Commons Exec
> Issue Type: Bug
>Affects Versions: 1.1
> Environment: Mac OsX 10.6.6, JVM 1.6.0
>Reporter: Jeremias Rößler
>Assignee: Siegfried Goeschl
> Labels: arguments, quotes, spaces
>
> I am new to Commons Exec, so this could also be an error in usage, but...
> When I use the {{CommandLine}} class to add a argument that contains spaces,
> some quotes are added and are then part of the argument that is given.
> For example: When I call {{java "what version"}} I get
> {{java.lang.NoClassDefFoundError: what version}}, and when I call {{java
> "\"what version\""}} (which contains escaped quotes, that are part of the
> command line argument itself), I get {{java.lang.NoClassDefFoundError: "what
> version"}}.
> So the following test fails, because as you can see in the last line, Apache
> Exec is producing the latter version where it should have produced the first
> version:
> {code:java}
> @Test
> public void testArgumentQuoting() throws Exception {
> String argument = "what version";
> DefaultExecutor executor = new DefaultExecutor();
> DefaultExecuteResultHandler resultHandler = new
> DefaultExecuteResultHandler();
> ByteArrayOutputStream out = new ByteArrayOutputStream();
> PumpStreamHandler streamHandler = new PumpStreamHandler(out,
> out);
> executor.setStreamHandler(streamHandler);
> CommandLine cmdLine = new CommandLine("java");
> cmdLine.addArgument(argument);
> executor.execute(cmdLine, resultHandler);
> resultHandler.waitFor();
> String resultPattern = "Exception in thread \"main\"
> java\\.lang\\.NoClassDefFoundError: ([\\w \"]+)";
> Pattern pattern = Pattern.compile(resultPattern);
> Matcher matcher = pattern.matcher(out.toString());
> Assert.assertTrue(matcher.find());
> // Note: Result should be and NOT <"what
> version">!
> Assert.assertEquals(argument, matcher.group(1));
> }
> {code}
> Note that the same test passes if the space is removed from the argument.
> Please also note, that I am not trying to start an external Java process, but
> this is merely an example that I assume will work on every developers machine.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectl
[jira] [Updated] (MATH-740) Some "FastMath" functions are slow
[ https://issues.apache.org/jira/browse/MATH-740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Hain updated MATH-740: --- Attachment: jafamatests.zip Jafama benches (and tests) stripped for apache FastMath, plus outputs of some runs. > Some "FastMath" functions are slow > -- > > Key: MATH-740 > URL: https://issues.apache.org/jira/browse/MATH-740 > Project: Commons Math > Issue Type: Wish >Reporter: Gilles >Priority: Minor > Fix For: 3.2 > > Attachments: jafamatests.zip > > > From the two benchmarks we currently have in "FastMathTestPerfomance", we > have that the following functions are much slower in "FastMath" than in > either "Math" or "StrictMath" (the performance *loss*, for each of the > benchmarks, is given in parentheses): > * log10 (46%, 36%) > * log1p (68%, 112%) > * tan (11%, 61%) > * atan (26%, 125%) > * atan2 (44%, 40%) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (EXEC-54) Problem with argument containing spaces
[
https://issues.apache.org/jira/browse/EXEC-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13583499#comment-13583499
]
DHadka edited comment on EXEC-54 at 2/21/13 8:08 PM:
-
I'm running into a similar issue as above. In my case, I want to pass a folder
on the command line, such as {{C:\Documents and Settings\user\folder\}}. So I
call
{noformat}command.addArgument("C:\\Documents and
Settings\\user\\folder\\"){noformat}
Commons Exec then adds the quotes around the argument. But on Windows, the
trailing \ in the path escapes the quote, which then is passed as part of the
argument. In this case, the program receives the argument as: {{C:\Documents
and Settings\users\folder"}}, with the quote as part of the argument. This
creates a subtle and hard to track error condition.
Consider these cases:
C:\NoSpace\in\path - Works correctly
C:\NoSpace\in\path\ - Works correctly (no quotes are added since no spaces in
path)
C:/NoSpace/in/path - Works correctly
C:/NoSpace/in/path/ - Works correctly
C:\With Space\in\path - Works correctly
C:\With Space\in\path\ - Fails due to this bug
C:/With Space/in/path - Works correctly
C:/With Space/in/path/ - Works correctly
was (Author: dhadka):
I'm running into a similar issue as above. In my case, I want to pass a
folder on the command line, such as {{C:\Documents and Settings\user\folder\}}.
So I call {{command.addArgument("C:\\Documents and
Settings\\user\\folder\\")}}. Commons Exec then adds the quotes around the
argument. But on Windows, the trailing \ in the path escapes the quote, which
then is passed as part of the argument. In this case, the program receives the
argument as: {{C:\Documents and Settings\users\folder"}}, with the quote as
part of the argument. This creates a subtle and hard to track error condition.
Consider these cases:
C:\NoSpace\in\path - Works correctly
C:\NoSpace\in\path\ - Works correctly (no quotes are added since no spaces in
path)
C:/NoSpace/in/path - Works correctly
C:/NoSpace/in/path/ - Works correctly
C:\With Space\in\path - Works correctly
C:\With Space\in\path\ - Fails due to this bug
C:/With Space/in/path - Works correctly
C:/With Space/in/path/ - Works correctly
> Problem with argument containing spaces
> ---
>
> Key: EXEC-54
> URL: https://issues.apache.org/jira/browse/EXEC-54
> Project: Commons Exec
> Issue Type: Bug
>Affects Versions: 1.1
> Environment: Mac OsX 10.6.6, JVM 1.6.0
>Reporter: Jeremias Rößler
>Assignee: Siegfried Goeschl
> Labels: arguments, quotes, spaces
>
> I am new to Commons Exec, so this could also be an error in usage, but...
> When I use the {{CommandLine}} class to add a argument that contains spaces,
> some quotes are added and are then part of the argument that is given.
> For example: When I call {{java "what version"}} I get
> {{java.lang.NoClassDefFoundError: what version}}, and when I call {{java
> "\"what version\""}} (which contains escaped quotes, that are part of the
> command line argument itself), I get {{java.lang.NoClassDefFoundError: "what
> version"}}.
> So the following test fails, because as you can see in the last line, Apache
> Exec is producing the latter version where it should have produced the first
> version:
> {code:java}
> @Test
> public void testArgumentQuoting() throws Exception {
> String argument = "what version";
> DefaultExecutor executor = new DefaultExecutor();
> DefaultExecuteResultHandler resultHandler = new
> DefaultExecuteResultHandler();
> ByteArrayOutputStream out = new ByteArrayOutputStream();
> PumpStreamHandler streamHandler = new PumpStreamHandler(out,
> out);
> executor.setStreamHandler(streamHandler);
> CommandLine cmdLine = new CommandLine("java");
> cmdLine.addArgument(argument);
> executor.execute(cmdLine, resultHandler);
> resultHandler.waitFor();
> String resultPattern = "Exception in thread \"main\"
> java\\.lang\\.NoClassDefFoundError: ([\\w \"]+)";
> Pattern pattern = Pattern.compile(resultPattern);
> Matcher matcher = pattern.matcher(out.toString());
> Assert.assertTrue(matcher.find());
> // Note: Result should be and NOT <"what
> version">!
> Assert.assertEquals(argument, matcher.group(1));
> }
> {code}
> Note that the same test passes if the space is removed from the argument.
> Please also note, that I am not trying to start an external Java process, but
> this is merely an example that I assume will work on every developers machine.
--
This message is automatically generated by JIRA.
If you t
[jira] [Commented] (LOGGING-144) LogFactory/LogFactoryImpl ingore Throwable
[ https://issues.apache.org/jira/browse/LOGGING-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13583520#comment-13583520 ] Thomas Neidhart commented on LOGGING-144: - Ok fine, I will then update the patch with your suggestion. Thanks again! > LogFactory/LogFactoryImpl ingore Throwable > -- > > Key: LOGGING-144 > URL: https://issues.apache.org/jira/browse/LOGGING-144 > Project: Commons Logging > Issue Type: Bug >Affects Versions: 1.1.1 >Reporter: Sebb > Attachments: LOGGING-144.patch > > > The code in LogFactory/LogFactoryImpl catches and ignores Throwable in > several places. > This is a bad idea, as some Throwables (e.g. ThreadDeath) should never be > ignored. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (EXEC-72) Using CommandLine with Set/Map containers
Mark Fuhs created EXEC-72: - Summary: Using CommandLine with Set/Map containers Key: EXEC-72 URL: https://issues.apache.org/jira/browse/EXEC-72 Project: Commons Exec Issue Type: Improvement Affects Versions: 1.1 Reporter: Mark Fuhs Priority: Minor CommandLine objects currently do not play well with Sets and Maps, because CommandLine does not implement equals() and hashCode(). This makes, for example, identifying/ignoring duplicate CommandLine objects more difficult than it should be. I think this would be a relatively quick-to-implement and straightforward improvement. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (BEANUTILS-409) BeanUtils - 'describe' method returning Incorrect array value
[
https://issues.apache.org/jira/browse/BEANUTILS-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter updated BEANUTILS-409:
--
Fix Version/s: 1.8.4
> BeanUtils - 'describe' method returning Incorrect array value
> -
>
> Key: BEANUTILS-409
> URL: https://issues.apache.org/jira/browse/BEANUTILS-409
> Project: Commons BeanUtils
> Issue Type: Bug
>Affects Versions: 1.8.3
> Environment: commons-beanutils 1.8.3, jdk 1.6.0_20
>Reporter: benny
>Priority: Critical
> Labels: describe
> Fix For: 1.8.4
>
>
> I want to convert a bean class to a map (key=the name of the member,value=the
> value of the member).
> I'm using the method BeanUtils.describe(beanClass);
> (I'm using commons-beanutils 1.8.3, jdk 1.6.0_20, on commons-beanutils 1.5 it
> works)
> The problem is that the return value is incorrect, (the map contain only the
> first item from the array),
> the code:
> public class Demo {
> private ArrayList myList = new ArrayList();
> public Demo() {
> myList.add("first_value");
> myList.add("second_value");
> }
>
> public ArrayList getMyList() {
> return myList;
> }
>
> public void setMyList(ArrayList myList) {
> this.myList = myList;
> }
>
> public static void main(String[] args) {
> Demo myBean = new Demo();
> try {
> Map describe = BeanUtils.describe(myBean);
> Iterator it = describe.entrySet().iterator();
> while (it.hasNext()) {
> Map.Entry pairs = (Map.Entry) it.next();
> System.out.println(String.format("key=%s,value=%s",
> (String) pairs.getKey(), (String) pairs.getValue()));
>
> }
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
> }
> •The expected output:
>
> key=myList,value=[first_value,second_value]
> key=class,value=class $Demo
> •But the real output is:
>
> key=myList,value=[first_value]
> key=class,value=class $Demo
> As you can see the array contains two values but the output(and the map)
> contains only one,why??
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (BEANUTILS-409) BeanUtils - 'describe' method returning Incorrect array value
[
https://issues.apache.org/jira/browse/BEANUTILS-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13583548#comment-13583548
]
Benedikt Ritter commented on BEANUTILS-409:
---
Senthil's observation is correct. I don't understand why the Converter does
only return the first element. I agree that this leads to strange behavior in
BeanUtils.describe().
I'll ask the ML for more information on this.
> BeanUtils - 'describe' method returning Incorrect array value
> -
>
> Key: BEANUTILS-409
> URL: https://issues.apache.org/jira/browse/BEANUTILS-409
> Project: Commons BeanUtils
> Issue Type: Bug
>Affects Versions: 1.8.3
> Environment: commons-beanutils 1.8.3, jdk 1.6.0_20
>Reporter: benny
>Priority: Critical
> Labels: describe
> Fix For: 1.8.4
>
>
> I want to convert a bean class to a map (key=the name of the member,value=the
> value of the member).
> I'm using the method BeanUtils.describe(beanClass);
> (I'm using commons-beanutils 1.8.3, jdk 1.6.0_20, on commons-beanutils 1.5 it
> works)
> The problem is that the return value is incorrect, (the map contain only the
> first item from the array),
> the code:
> public class Demo {
> private ArrayList myList = new ArrayList();
> public Demo() {
> myList.add("first_value");
> myList.add("second_value");
> }
>
> public ArrayList getMyList() {
> return myList;
> }
>
> public void setMyList(ArrayList myList) {
> this.myList = myList;
> }
>
> public static void main(String[] args) {
> Demo myBean = new Demo();
> try {
> Map describe = BeanUtils.describe(myBean);
> Iterator it = describe.entrySet().iterator();
> while (it.hasNext()) {
> Map.Entry pairs = (Map.Entry) it.next();
> System.out.println(String.format("key=%s,value=%s",
> (String) pairs.getKey(), (String) pairs.getValue()));
>
> }
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
> }
> •The expected output:
>
> key=myList,value=[first_value,second_value]
> key=class,value=class $Demo
> •But the real output is:
>
> key=myList,value=[first_value]
> key=class,value=class $Demo
> As you can see the array contains two values but the output(and the map)
> contains only one,why??
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (BEANUTILS-409) BeanUtils - 'describe' method returning Incorrect array value
[
https://issues.apache.org/jira/browse/BEANUTILS-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter updated BEANUTILS-409:
--
Attachment: BEANUTILS-409-Test.patch
Added patch for BeanUtilsTestCase that shows the strange behavior.
> BeanUtils - 'describe' method returning Incorrect array value
> -
>
> Key: BEANUTILS-409
> URL: https://issues.apache.org/jira/browse/BEANUTILS-409
> Project: Commons BeanUtils
> Issue Type: Bug
>Affects Versions: 1.8.3
> Environment: commons-beanutils 1.8.3, jdk 1.6.0_20
>Reporter: benny
>Assignee: Benedikt Ritter
>Priority: Critical
> Labels: describe
> Fix For: 1.8.4
>
> Attachments: BEANUTILS-409-Test.patch
>
>
> I want to convert a bean class to a map (key=the name of the member,value=the
> value of the member).
> I'm using the method BeanUtils.describe(beanClass);
> (I'm using commons-beanutils 1.8.3, jdk 1.6.0_20, on commons-beanutils 1.5 it
> works)
> The problem is that the return value is incorrect, (the map contain only the
> first item from the array),
> the code:
> public class Demo {
> private ArrayList myList = new ArrayList();
> public Demo() {
> myList.add("first_value");
> myList.add("second_value");
> }
>
> public ArrayList getMyList() {
> return myList;
> }
>
> public void setMyList(ArrayList myList) {
> this.myList = myList;
> }
>
> public static void main(String[] args) {
> Demo myBean = new Demo();
> try {
> Map describe = BeanUtils.describe(myBean);
> Iterator it = describe.entrySet().iterator();
> while (it.hasNext()) {
> Map.Entry pairs = (Map.Entry) it.next();
> System.out.println(String.format("key=%s,value=%s",
> (String) pairs.getKey(), (String) pairs.getValue()));
>
> }
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
> }
> •The expected output:
>
> key=myList,value=[first_value,second_value]
> key=class,value=class $Demo
> •But the real output is:
>
> key=myList,value=[first_value]
> key=class,value=class $Demo
> As you can see the array contains two values but the output(and the map)
> contains only one,why??
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (BEANUTILS-409) BeanUtils - 'describe' method returning Incorrect array value
[
https://issues.apache.org/jira/browse/BEANUTILS-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13583632#comment-13583632
]
Senthil Kumar Balakrishnan commented on BEANUTILS-409:
--
Thanks Benedikt, I would like to contribute in what ever way. I would be glad
to make the fix, will wait to hear on the outcome from ML.
> BeanUtils - 'describe' method returning Incorrect array value
> -
>
> Key: BEANUTILS-409
> URL: https://issues.apache.org/jira/browse/BEANUTILS-409
> Project: Commons BeanUtils
> Issue Type: Bug
>Affects Versions: 1.8.3
> Environment: commons-beanutils 1.8.3, jdk 1.6.0_20
>Reporter: benny
>Assignee: Benedikt Ritter
>Priority: Critical
> Labels: describe
> Fix For: 1.8.4
>
> Attachments: BEANUTILS-409-Test.patch
>
>
> I want to convert a bean class to a map (key=the name of the member,value=the
> value of the member).
> I'm using the method BeanUtils.describe(beanClass);
> (I'm using commons-beanutils 1.8.3, jdk 1.6.0_20, on commons-beanutils 1.5 it
> works)
> The problem is that the return value is incorrect, (the map contain only the
> first item from the array),
> the code:
> public class Demo {
> private ArrayList myList = new ArrayList();
> public Demo() {
> myList.add("first_value");
> myList.add("second_value");
> }
>
> public ArrayList getMyList() {
> return myList;
> }
>
> public void setMyList(ArrayList myList) {
> this.myList = myList;
> }
>
> public static void main(String[] args) {
> Demo myBean = new Demo();
> try {
> Map describe = BeanUtils.describe(myBean);
> Iterator it = describe.entrySet().iterator();
> while (it.hasNext()) {
> Map.Entry pairs = (Map.Entry) it.next();
> System.out.println(String.format("key=%s,value=%s",
> (String) pairs.getKey(), (String) pairs.getValue()));
>
> }
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
> }
> •The expected output:
>
> key=myList,value=[first_value,second_value]
> key=class,value=class $Demo
> •But the real output is:
>
> key=myList,value=[first_value]
> key=class,value=class $Demo
> As you can see the array contains two values but the output(and the map)
> contains only one,why??
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COMPRESS-219) ZipArchiveInputStream: ArrayIndexOutOfBoundsException when extracting a STORED zip file entry from within a zip.
[ https://issues.apache.org/jira/browse/COMPRESS-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig resolved COMPRESS-219. - Resolution: Fixed Test committed, thanks! > ZipArchiveInputStream: ArrayIndexOutOfBoundsException when extracting a > STORED zip file entry from within a zip. > > > Key: COMPRESS-219 > URL: https://issues.apache.org/jira/browse/COMPRESS-219 > Project: Commons Compress > Issue Type: Bug > Components: Archivers >Affects Versions: 1.4.1 > Environment: Windows (Linux as well) >Reporter: Wurstbrot mit Senf >Priority: Minor > Fix For: 1.5 > > Attachments: compress-219-test.patch, test-linux.zip, > ZipArchiveInputStreamTest.java > > > When trying to read out a ZIP file, that has been stored (Method STORE, not > DEFLATE!, with DEFLATE it seems OK) in another ZIP file using the > ZipArchiveInputStream, I do get an ArrayIndexOutOfBoundsException when doing > the arraycopy in ZipArchiveInputStream#readStored(byte[], int, int) (line > 362) because the "toRead" is not decreased by the buf.offsetInBuffer. > I will add the zip in question as attachment. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (VFS-451) Authentication fails using private key
[ https://issues.apache.org/jira/browse/VFS-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joerg Schaible resolved VFS-451. Resolution: Duplicate Changes reverted, resolved as duplicate, since VFS-283 supersedes this issue. $ svn ci -m "Reverted change 1433253 of VFS-451." Sending core/src/main/java/org/apache/commons/vfs2/provider/sftp/SftpClientFactory.java Sendingsrc/changes/changes.xml Sendingsrc/site/xdoc/testing.xml Transmitting file data .. Committed revision 1448916. > Authentication fails using private key > -- > > Key: VFS-451 > URL: https://issues.apache.org/jira/browse/VFS-451 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.0 > Environment: windows as client > linux as ssh server >Reporter: Marco Ronchi >Assignee: Joerg Schaible > Fix For: 2.1 > > Attachments: SftpClientFactory.java.patch, SimpleTest.java, > vfs-patch-2.txt > > > Cannot connect to a ssh server with my private key. > I believe the issue is due to an JSCH bug. > Using the following lines: > session.setPassword(pass); > jsch.addIdentity(identityfile); > instead of > jsch.addIdentity(privateKeyFilePath,password); > authentication fails. > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
