[jira] [Commented] (CODEC-134) Base32 would decode some invalid Base32 encoded string into arbitrary value
[ https://issues.apache.org/jira/browse/CODEC-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865221#comment-16865221 ] Pavan Raju commented on CODEC-134: -- Hey folks, Thanks for the fix above! Much appreciated. Is there a plan for a release coming up soon? We're also looking at using the 1.13 release. Thanks, Pavan > Base32 would decode some invalid Base32 encoded string into arbitrary value > --- > > Key: CODEC-134 > URL: https://issues.apache.org/jira/browse/CODEC-134 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.6 > Environment: All >Reporter: Hanson Char >Assignee: Gary Gregory >Priority: Major > Labels: security > Fix For: 1.13 > > Attachments: diff-120305-20.txt > > Time Spent: 10m > Remaining Estimate: 0h > > Example, there is no byte array value that can be encoded into the string > "C5CYMIHWQUUZMKUGZHGEOSJSQDE4L===", but the existing Base32 implementation > would not reject it but decode it into an arbitrary value which if re-encoded > again using the same implementation would result in the string > "C5CYMIHWQUUZMKUGZHGEOSJSQDE4K===". > Instead of blindly decoding the invalid string, the Base32 codec should > reject it (eg by throwing IlleglArgumentException) to avoid security > exploitation (such as tunneling additional information via seemingly valid > base 32 strings). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [commons-vfs] garydgregory commented on issue #65: VFS-619 Fixes performance issue with SftpFileObject.getChildren()
garydgregory commented on issue #65: VFS-619 Fixes performance issue with SftpFileObject.getChildren() URL: https://github.com/apache/commons-vfs/pull/65#issuecomment-502495691 Fixed in `changes.xml`, thanks @DavidSeptimus. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Closed] (VFS-698) SFTP file attributes are fetched multiple times leading to very slow directory listing
[
https://issues.apache.org/jira/browse/VFS-698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory closed VFS-698.
Resolution: Fixed
Fix Version/s: 2.4
> SFTP file attributes are fetched multiple times leading to very slow
> directory listing
> --
>
> Key: VFS-698
> URL: https://issues.apache.org/jira/browse/VFS-698
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: krishnan
>Priority: Major
> Fix For: 2.4
>
>
> getChildren() applied on SftpFileObject is very slow compared to JSCH
> implementation. This is because, the SftpATTRS which is readily available for
> the children after an "ls" call is again fetched for each child file since
> they are independently resolved. So if a directory contains 10 files, it
> results in 1 (ls) + 10 (stat) calls to server.
> For a folder with 100 files (AWS), it took about 35 secs instead of 1.5 secs
> to getChildren().
>
> *doListChildrenResolved:*
> {{final FileObject fo =
> getFileSystem().resolveFile(getFileSystem().getFileSystemManager()}}
> \{{ .resolveName(getName(), UriParser.encode(name), NameScope.CHILD));}}
> {{{color:#ff}((SftpFileObject)
> FileObjectUtils.getAbstractFileObject(fo)).setStat(stat.getAttrs());{color}}}
>
> The resolveFile call, creates a SftpFileObject and calls its resolve method,
> which results in getting the (stats) SftpATTRS for each child file. This stat
> is already available as part of the 'ls' call we made. The setStat call above
> (highlighted is red) is redundant, since stat for each child file is already
> fetched one at a time.
> The solution would be to avoid getting the stat for each child file after an
> 'ls' call. May be, the framework makes it difficult to do this easily.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [commons-vfs] DavidSeptimus commented on issue #65: VFS-619 Fixes performance issue with SftpFileObject.getChildren()
DavidSeptimus commented on issue #65: VFS-619 Fixes performance issue with SftpFileObject.getChildren() URL: https://github.com/apache/commons-vfs/pull/65#issuecomment-502493920 Ah, I just realized that I referenced the wrong Jira story. It should have been VFS-698. https://issues.apache.org/jira/browse/VFS-698 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Resolved] (NET-670) Apache Commons Net ftpClient.java changeWorkingDirectory() Function CRLF Injection Remote Command Execution
[ https://issues.apache.org/jira/browse/NET-670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved NET-670. -- Resolution: Not A Bug > Apache Commons Net ftpClient.java changeWorkingDirectory() Function CRLF > Injection Remote Command Execution > --- > > Key: NET-670 > URL: https://issues.apache.org/jira/browse/NET-670 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 3.6 >Reporter: David Hurst >Priority: Critical > Labels: patch > Fix For: 3.7 > > > Per BlackDuck Hub VulnDB 171100 > Apache Commons Net contains a flaw in the changeWorkingDirectory() function > in ftpClient.java that is triggered as user-supplied input is not properly > sanitized. This may allow a remote attacker to use a newline character in a > specially crafted string to execute arbitrary commands. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NET-670) Apache Commons Net ftpClient.java changeWorkingDirectory() Function CRLF Injection Remote Command Execution
[ https://issues.apache.org/jira/browse/NET-670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865195#comment-16865195 ] Sebb commented on NET-670: -- NET is intended as a low-level interface to various internet protocols. The caller application must validate user input before calling NET methods. > Apache Commons Net ftpClient.java changeWorkingDirectory() Function CRLF > Injection Remote Command Execution > --- > > Key: NET-670 > URL: https://issues.apache.org/jira/browse/NET-670 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 3.6 >Reporter: David Hurst >Priority: Critical > Labels: patch > Fix For: 3.7 > > > Per BlackDuck Hub VulnDB 171100 > Apache Commons Net contains a flaw in the changeWorkingDirectory() function > in ftpClient.java that is triggered as user-supplied input is not properly > sanitized. This may allow a remote attacker to use a newline character in a > specially crafted string to execute arbitrary commands. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CODEC-256) ColognePhonetic.encode() calculates wrong code
[ https://issues.apache.org/jira/browse/CODEC-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865193#comment-16865193 ] Sebb commented on CODEC-256: Are you sure that code 0 is completely ignored? According to Wikipedia, code 0 is dropped AFTER duplicates have been eliminated, not before. That makes more sense, as we then get: Roman => 70606 => 766 Rom => 706 => 76 rather than both having the value 76. Unless there is independent evidence that 0 is eliminated before de-duplication, I think this issue is invalid > ColognePhonetic.encode() calculates wrong code > -- > > Key: CODEC-256 > URL: https://issues.apache.org/jira/browse/CODEC-256 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.12 > Environment: Java 8u181 64, Windows 7 Professional 64 >Reporter: Andreas Schnur >Priority: Major > Attachments: ColognePhonetic.java > > > Example String: "ARTMANN". Code of M is 6, Code of A is Zero (and therefore > is left out), Code of N is 6 and should be left out because 6 is previous, > but Code assumes wrongly 0 as previous (which was left out). So the result is > 07266, but has to be 0726 (see Description of algorithm in class). > Solution: In method colognePhonetic() move the last two LOC into if-block > above, see attached version of class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (VFS-717) Update org.apache.httpcomponents:httpclient from 4.5.8 to 4.5.9.
[ https://issues.apache.org/jira/browse/VFS-717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated VFS-717: - Summary: Update org.apache.httpcomponents:httpclient from 4.5.8 to 4.5.9. (was: Udpate org.apache.httpcomponents:httpclient from 4.5.8 to 4.5.9.) > Update org.apache.httpcomponents:httpclient from 4.5.8 to 4.5.9. > > > Key: VFS-717 > URL: https://issues.apache.org/jira/browse/VFS-717 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Gary Gregory >Priority: Major > > Udpate org.apache.httpcomponents:httpclient from 4.5.8 to 4.5.9. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CODEC-253) Upgrade to Java 8
[ https://issues.apache.org/jira/browse/CODEC-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865189#comment-16865189 ] Sebb commented on CODEC-253: Agree with Michael and Emmanuel. Code should remain on Java 7 until such time as there is a genuine need to upgrade to the next version of Java. > Upgrade to Java 8 > - > > Key: CODEC-253 > URL: https://issues.apache.org/jira/browse/CODEC-253 > Project: Commons Codec > Issue Type: Improvement >Reporter: Rob Tompkins >Assignee: Rob Tompkins >Priority: Major > Fix For: 1.13 > > > Upgrade to java 8 as the target of of the build. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (VFS-717) Update org.apache.httpcomponents:httpclient from 4.5.8 to 4.5.9.
[ https://issues.apache.org/jira/browse/VFS-717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated VFS-717: - Description: Update org.apache.httpcomponents:httpclient from 4.5.8 to 4.5.9. (was: Udpate org.apache.httpcomponents:httpclient from 4.5.8 to 4.5.9.) > Update org.apache.httpcomponents:httpclient from 4.5.8 to 4.5.9. > > > Key: VFS-717 > URL: https://issues.apache.org/jira/browse/VFS-717 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Gary Gregory >Priority: Major > > Update org.apache.httpcomponents:httpclient from 4.5.8 to 4.5.9. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (CODEC-253) Upgrade to Java 8
[ https://issues.apache.org/jira/browse/CODEC-253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb reopened CODEC-253: This issue has not been properly resolved > Upgrade to Java 8 > - > > Key: CODEC-253 > URL: https://issues.apache.org/jira/browse/CODEC-253 > Project: Commons Codec > Issue Type: Improvement >Reporter: Rob Tompkins >Assignee: Rob Tompkins >Priority: Major > Fix For: 1.13 > > > Upgrade to java 8 as the target of of the build. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (VFS-717) Udpate org.apache.httpcomponents:httpclient from 4.5.8 to 4.5.9.
[ https://issues.apache.org/jira/browse/VFS-717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated VFS-717: - Summary: Udpate org.apache.httpcomponents:httpclient from 4.5.8 to 4.5.9. (was: Udpate org.apache.httpcomponents:httpclient fro) > Udpate org.apache.httpcomponents:httpclient from 4.5.8 to 4.5.9. > > > Key: VFS-717 > URL: https://issues.apache.org/jira/browse/VFS-717 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Gary Gregory >Priority: Major > > Udpate org.apache.httpcomponents:httpclient from 4.5.8 to 4.5.9. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (VFS-717) Udpate org.apache.httpcomponents:httpclient fro
Gary Gregory created VFS-717: Summary: Udpate org.apache.httpcomponents:httpclient fro Key: VFS-717 URL: https://issues.apache.org/jira/browse/VFS-717 Project: Commons VFS Issue Type: Bug Affects Versions: 2.3 Reporter: Gary Gregory Udpate org.apache.httpcomponents:httpclient from 4.5.8 to 4.5.9. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (EMAIL-188) Issues with Apache commons email library
[ https://issues.apache.org/jira/browse/EMAIL-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved EMAIL-188. Resolution: Not A Bug > Issues with Apache commons email library > > > Key: EMAIL-188 > URL: https://issues.apache.org/jira/browse/EMAIL-188 > Project: Commons Email > Issue Type: Bug >Reporter: Anurag Garg >Priority: Major > > Hi team, > We are facing below issues with apache commons email library > 1) When a user is sending email having inline image in body along with image > as an attachment in that case when we are calling getAttachments() method of > MimeMessageparser it is giving both the images because of that we are not > able to distinguish between the actual image as attachment vs inline image. > 2) When a user is sending email with .msg file as attachment in that case it > is not even coming as attachment when we are calling getAttachments() method > of MimeMessageparser. > Not sure if the above behavior is expected or not? Can you please look into > this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (VFS-619) Issue creating HttpClient timeout
[
https://issues.apache.org/jira/browse/VFS-619?focusedWorklogId=261071=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-261071
]
ASF GitHub Bot logged work on VFS-619:
--
Author: ASF GitHub Bot
Created on: 16/Jun/19 22:23
Start Date: 16/Jun/19 22:23
Worklog Time Spent: 10m
Work Description: garydgregory commented on pull request #65: VFS-619
Fixes performance issue with SftpFileObject.getChildren()
URL: https://github.com/apache/commons-vfs/pull/65
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 261071)
Time Spent: 20m (was: 10m)
> Issue creating HttpClient timeout
> -
>
> Key: VFS-619
> URL: https://issues.apache.org/jira/browse/VFS-619
> Project: Commons VFS
> Issue Type: Bug
>Reporter: Ben Xiang
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Hi,
> Recently we met an issue that the thread got stuck during the http connection
> using HttpClient. And It showed that the connection timeout was set to 0,
> which was not what we set.
> let me briefly show here how we are using VFS2:
> Create a FileSystemOptions with timeout set:
> {code}
> final FileSystemOptions fso = new FileSystemOptions();
> final HttpFileSystemConfigBuilder httpBuilder =
> HttpFileSystemConfigBuilder.getInstance();
> httpBuilder.setConnectionTimeout(fso, connectionTimeout);
> httpBuilder.setSoTimeout(fso, soTimeout);
> {code}
> Create a FileObject using FileSystemManager:
> {code}
> vfs2FileManager.resolveFile(fileLocation, fso);
> {code}
> Finally get the input stream using DefaultFileContent:
> {code}
> final InputStream instr = fileObject.getInputStream();
> {code}
> We noticed that in executeMethod() of HttpMethodDirector, line 153, it is
> setting the connection timeout using client's params. However,
> in HttpClientFactory, it's setting fileSystemOptions in connectionMgrParams,
> and the HttpClient's params would not have this value.
> So we added following 2 lines to make it work:
> In package org.apache.commons.vfs2.provider.http, HttpClientFactory, added
> line 148 and 149:
> {code}
> client.getParams().setConnectionManagerTimeout(connectionMgrParams.getConnectionTimeout());
> client.getParams().setSoTimeout(connectionMgrParams.getSoTimeout());
> {code}
> Please let me know your thought about this and if there is a patch needed, or
> is there something we are missing or doing wrong ?
> Thanks!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [commons-vfs] garydgregory merged pull request #65: VFS-619 Fixes performance issue with SftpFileObject.getChildren()
garydgregory merged pull request #65: VFS-619 Fixes performance issue with SftpFileObject.getChildren() URL: https://github.com/apache/commons-vfs/pull/65 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-vfs] garydgregory commented on issue #65: VFS-619 Fixes performance issue with SftpFileObject.getChildren()
garydgregory commented on issue #65: VFS-619 Fixes performance issue with SftpFileObject.getChildren() URL: https://github.com/apache/commons-vfs/pull/65#issuecomment-502490732 Squashing and merged. @DavidSeptimus & @ecki Thank you. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Created] (IO-609) FileUtils.copyToFile backward incompatibility bug
Lingchao Chen created IO-609:
Summary: FileUtils.copyToFile backward incompatibility bug
Key: IO-609
URL: https://issues.apache.org/jira/browse/IO-609
Project: Commons IO
Issue Type: Bug
Affects Versions: 2.6
Reporter: Lingchao Chen
Hi,
The following code snippets throw an IOException: Stream closed. It works well
before commons-io 2.6. When I update commons-io to 2.6, it failed. There is a
backward incompatibility bug behind it.
The function code:
{code:java}
public class Demo {
private void backupFile(String srcPath, String entryPath,
ZipOutputStream stream) throws IOException {
ZipEntry zipEntry = new ZipEntry(entryPath);
stream.putNextEntry(zipEntry);
Files.copy(Paths.get(srcPath), stream);
}
private void backupDir(String srcDir, String dstDir, ZipOutputStream
stream) throws IOException {
File dir = new File(srcDir);
for (String path : dir.list()) {
System.out.println(path);
backupFile(dir.getAbsolutePath() + File.separator + path,
dstDir + File.separator + path, stream);
}
}
public void backup(String name) throws IOException {
Files.createDirectories(Paths.get("/Users/chenlingchao/eclipse_projects/workspace/BBI.BugDetection"));
ZipOutputStream stream = new ZipOutputStream(
Files.newOutputStream(Paths.get("/Users/chenlingchao/eclipse_projects/workspace/BBI.BugDetection/tmp"
+ File.separator + name)));
try {
backupDir("/Users/chenlingchao/eclipse_projects/workspace/BBI.BugDetection/tmp",
"meta" + File.separator + "tables", stream);
stream.closeEntry();
} finally {
stream.close();
}
}
public void restore(String name) throws IOException {
ZipInputStream stream = new ZipInputStream(
Files.newInputStream(Paths.get("/Users/chenlingchao/eclipse_projects/workspace/BBI.BugDetection/tmp"
+ File.separator + name)));
try {
ZipEntry entry;
while ((entry = stream.getNextEntry()) != null) {
FileUtils.copyToFile(stream, new
File("/Users/chenlingchao/eclipse_projects/workspace/BBI.BugDetection/tmp" +
File.separator + entry.getName()));
}
} finally {
stream.close();
}
}
}
{code}
The test code:
{code:java}
@Test
public void TestDemo() throws IOException{
Demo test = new Demo();
test.backup("test.zip");
test.restore("test.zip");
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (COMMONSSITE-100) "mvn site" fails with commons-parent 43
[
https://issues.apache.org/jira/browse/COMMONSSITE-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865184#comment-16865184
]
Gilles edited comment on COMMONSSITE-100 at 6/16/19 10:03 PM:
--
Issue still exists when running
{noformat}
$ mvn clean site
{noformat}
for "Commons Math" after upgrading to CP 48 (cf. commit
418f2eb7f469c80b0e125377b1669f9be068f6ff on "master").
was (Author: erans):
Issue still exists on my machine with CP 48 (as of commit
418f2eb7f469c80b0e125377b1669f9be068f6ff on "master").
> "mvn site" fails with commons-parent 43
> ---
>
> Key: COMMONSSITE-100
> URL: https://issues.apache.org/jira/browse/COMMONSSITE-100
> Project: Commons All
> Issue Type: Bug
> Components: Commons Parent Pom
>Reporter: Gilles
>Priority: Major
>
> See [this post|http://markmail.org/message/zgfb5h774aigatx2].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COMMONSSITE-100) "mvn site" fails with commons-parent 43
[ https://issues.apache.org/jira/browse/COMMONSSITE-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865184#comment-16865184 ] Gilles commented on COMMONSSITE-100: Issue still exists on my machine with CP 48 (as of commit 418f2eb7f469c80b0e125377b1669f9be068f6ff on "master"). > "mvn site" fails with commons-parent 43 > --- > > Key: COMMONSSITE-100 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-100 > Project: Commons All > Issue Type: Bug > Components: Commons Parent Pom >Reporter: Gilles >Priority: Major > > See [this post|http://markmail.org/message/zgfb5h774aigatx2]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (COLLECTIONS-721) functors.InvokerTransformer backward incompatibility bug
Lingchao Chen created COLLECTIONS-721:
-
Summary: functors.InvokerTransformer backward incompatibility bug
Key: COLLECTIONS-721
URL: https://issues.apache.org/jira/browse/COLLECTIONS-721
Project: Commons Collections
Issue Type: Bug
Affects Versions: 4.3, 4.2, 4.1
Reporter: Lingchao Chen
The following code snippets throw a NotSerializableException. It works well
before commons-collections4 4.0 and commons-collection3. When I update it to
4.1 or newer versions, it failed.
{code:java}
@Test
public void Demo() throws IOException{
InvokerTransformer transformer = new
InvokerTransformer("toString", new Class[]{}, new Object[]{});
Queue priorityQueue = new PriorityQueue(2, new
TransformingComparator(transformer));
priorityQueue.add(1);
ByteArrayOutputStream bout = new ByteArrayOutputStream();
ObjectOutputStream out = new ObjectOutputStream(bout);
out.writeObject(priorityQueue);
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MATH-1489) Test failure because of incompatible version specification of JaCoCo in pom.xml
[
https://issues.apache.org/jira/browse/MATH-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865178#comment-16865178
]
Gilles commented on MATH-1489:
--
Thanks for the report.
I've attempted some cleanup and
{noformat}
$ mvn clean package
{noformat}
should work (if we exclude the {{FastMathTest}} failure) as of commit
418f2eb7f469c80b0e125377b1669f9be068f6ff ("master").
However
{noformat}
$ mvn clean site
{noformat}
fails while building the Javadoc.
> Test failure because of incompatible version specification of JaCoCo in
> pom.xml
> ---
>
> Key: MATH-1489
> URL: https://issues.apache.org/jira/browse/MATH-1489
> Project: Commons Math
> Issue Type: Bug
> Environment: OpenJDK 11.0.3
> Debian GNU/Linux 9.9 stretch
>
>Reporter: M. Z.
>Priority: Critical
> Labels: build, easyfix, newbie
> Attachments: commons-math-buildlog-2019-06-15.log
>
> Original Estimate: 10m
> Remaining Estimate: 10m
>
> I've experienced constant build failures on the attempt to "mvn clean package"
> on a working copy of [http://gitbox.apache.org/repos/asf/commons-math.git] (
> commit 4b0f52c0dd9df564d58140e1d717a2da218f0139 )
> It has to do with the specified version of jacoco in pom.xml. See attached
> buildlog for concrete error.
> My solution:
> $ git diff
> --- a/pom.xml
> +++ b/pom.xml
> @@ -493,7 +493,7 @@
> 2.7.2
>
>
> - 0.8.0
> + 0.8.4
> 0.96
> 0.8
> 0.8
>
> See
> [https://stackoverflow.com/questions/55272870/surefire-maven-plugin-corrupted-stdout-by-directly-writing-to-native-stream-in]
> for a previously reported issue with the use jacoco and OpenJDK 11.
> After the proposed change, I've got
> $ mvn clean package
>
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR] FastMathTest.checkMissingFastMathClasses:1275 FastMath should
> implement all StrictMath methods
> [INFO]
> [ERROR] Tests run: 4864, Failures: 1, Errors: 0, Skipped: 31
> [INFO]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> ...
> So tests should have been executed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (LANG-1465) DateUtils.parseDate backward Incompatibility bug
Lingchao Chen created LANG-1465:
---
Summary: DateUtils.parseDate backward Incompatibility bug
Key: LANG-1465
URL: https://issues.apache.org/jira/browse/LANG-1465
Project: Commons Lang
Issue Type: Bug
Components: lang.time.*
Affects Versions: 3.8.1, 3.9, 3.8, 3.7, 3.6, 3.5
Environment: System: Linux testinglab 4.4.0-131-generic
#157~14.04.1-Ubuntu
Java version "1.8.0_191"
Java(TM) SE Runtime Environment (build 1.8.0_191-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.191-b12, mixed mode)
Reporter: Lingchao Chen
Hi,
The following code snippets throw a ParseException when trying to parse the
time. It works well before commons-lang 3.4. When I update commons-lang to 3.5
or newer versions, it failed.
{code:java}
@Test
public void Demo() throws ParseException {
assertEquals("Tue Jun 11 15:06:11 CDT 2019",
DateUtils.parseDate("2019-06-11T15:06:11.716-0500",
"-MM-dd'T'HH:mm:ss.SSSZZ"));
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CSV-135) Char escape doesn't work properly with quoting
[
https://issues.apache.org/jira/browse/CSV-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865157#comment-16865157
]
Opher Shachar commented on CSV-135:
---
Sorry, I probably did not make my point clear before.
If the field value is:
* "D:\Property Documents\ID 1.docx"
the `\` is obviously a literal not an escape. While for
* "3rd Lincoln boulevard\, Miami\, FL"
the `\` may or may-not be an escape.
The solution could be by adding a new flag (or a new {{enum}}) that modifies
{{QuoteMode}}'s handling by making it explicit whether `\` are literals, or an
escape only if followed by specific chars (i.e. `,`,`\`) or always an escape.
> Char escape doesn't work properly with quoting
> --
>
> Key: CSV-135
> URL: https://issues.apache.org/jira/browse/CSV-135
> Project: Commons CSV
> Issue Type: Bug
> Components: Printer
>Affects Versions: 1.0
>Reporter: Mateusz Zakarczemny
>Priority: Major
> Fix For: Patch Needed
>
>
> Following code:
> {code}
> CSVFormat format = CSVFormat.DEFAULT
> .withRecordSeparator('\n')
> .withQuote('"')
> .withEscape('\\');
> CSVPrinter printer = new CSVPrinter(System.out, format);
> List l = new LinkedList();
> l.add("\"");
> l.add("\n");
> l.add("\\");
> printer.printRecord(l);
> {code}
> produces
> {code}
> ,"
> ","\"
> {code}
> instead of
> {code}
> "\"","\n","\\"
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [commons-vfs] DavidSeptimus commented on issue #65: VFS-619 Fixes performance issue with SftpFileObject.getChildren()
DavidSeptimus commented on issue #65: VFS-619 Fixes performance issue with SftpFileObject.getChildren() URL: https://github.com/apache/commons-vfs/pull/65#issuecomment-502484151 That's a fair point. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-vfs] ecki commented on issue #65: VFS-619 Fixes performance issue with SftpFileObject.getChildren()
ecki commented on issue #65: VFS-619 Fixes performance issue with SftpFileObject.getChildren() URL: https://github.com/apache/commons-vfs/pull/65#issuecomment-502483677 It is probably better to remove this refresh implementation completely, the super implementation will call detach/doDetach which already sets `attrs = null` This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Created] (MATH-1491) Percentile computational accuracy issue
Lingchao Chen created MATH-1491: --- Summary: Percentile computational accuracy issue Key: MATH-1491 URL: https://issues.apache.org/jira/browse/MATH-1491 Project: Commons Math Issue Type: Bug Affects Versions: 3.6.1, 3.6, 3.5, 3.4.1, 3.4 Environment: System: Linux testinglab 4.4.0-131-generic #157~14.04.1-Ubuntu Java version "1.8.0_191" Java(TM) SE Runtime Environment (build 1.8.0_191-b12) Java HotSpot(TM) 64-Bit Server VM (build 25.191-b12, mixed mode) Reporter: Lingchao Chen Attachments: BugDemo.java Hi, The percentile method works well on the older versions, e.g., the version before 3.4. However, when I update commons-math to the newer version, there produces a computational accuracy issue. There is a backward compatibility bug behind it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CSV-135) Char escape doesn't work properly with quoting
[
https://issues.apache.org/jira/browse/CSV-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved CSV-135.
--
Resolution: Fixed
7754cd4 CSV-135 - Char escape doesn't work properly with quoting
> Char escape doesn't work properly with quoting
> --
>
> Key: CSV-135
> URL: https://issues.apache.org/jira/browse/CSV-135
> Project: Commons CSV
> Issue Type: Bug
> Components: Printer
>Affects Versions: 1.0
>Reporter: Mateusz Zakarczemny
>Priority: Major
> Fix For: Patch Needed
>
>
> Following code:
> {code}
> CSVFormat format = CSVFormat.DEFAULT
> .withRecordSeparator('\n')
> .withQuote('"')
> .withEscape('\\');
> CSVPrinter printer = new CSVPrinter(System.out, format);
> List l = new LinkedList();
> l.add("\"");
> l.add("\n");
> l.add("\\");
> printer.printRecord(l);
> {code}
> produces
> {code}
> ,"
> ","\"
> {code}
> instead of
> {code}
> "\"","\n","\\"
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-698) SFTP file attributes are fetched multiple times leading to very slow directory listing
[
https://issues.apache.org/jira/browse/VFS-698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865152#comment-16865152
]
David Septimus commented on VFS-698:
PR raised: [https://github.com/apache/commons-vfs/pull/65]
> SFTP file attributes are fetched multiple times leading to very slow
> directory listing
> --
>
> Key: VFS-698
> URL: https://issues.apache.org/jira/browse/VFS-698
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: krishnan
>Priority: Major
>
> getChildren() applied on SftpFileObject is very slow compared to JSCH
> implementation. This is because, the SftpATTRS which is readily available for
> the children after an "ls" call is again fetched for each child file since
> they are independently resolved. So if a directory contains 10 files, it
> results in 1 (ls) + 10 (stat) calls to server.
> For a folder with 100 files (AWS), it took about 35 secs instead of 1.5 secs
> to getChildren().
>
> *doListChildrenResolved:*
> {{final FileObject fo =
> getFileSystem().resolveFile(getFileSystem().getFileSystemManager()}}
> \{{ .resolveName(getName(), UriParser.encode(name), NameScope.CHILD));}}
> {{{color:#ff}((SftpFileObject)
> FileObjectUtils.getAbstractFileObject(fo)).setStat(stat.getAttrs());{color}}}
>
> The resolveFile call, creates a SftpFileObject and calls its resolve method,
> which results in getting the (stats) SftpATTRS for each child file. This stat
> is already available as part of the 'ls' call we made. The setStat call above
> (highlighted is red) is redundant, since stat for each child file is already
> fetched one at a time.
> The solution would be to avoid getting the stat for each child file after an
> 'ls' call. May be, the framework makes it difficult to do this easily.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Work logged] (VFS-619) Issue creating HttpClient timeout
[
https://issues.apache.org/jira/browse/VFS-619?focusedWorklogId=261060=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-261060
]
ASF GitHub Bot logged work on VFS-619:
--
Author: ASF GitHub Bot
Created on: 16/Jun/19 20:23
Start Date: 16/Jun/19 20:23
Worklog Time Spent: 10m
Work Description: DavidSeptimus commented on pull request #65: VFS-619
Fixes performance issue with SftpFileObject.getChildren()
URL: https://github.com/apache/commons-vfs/pull/65
This PR removes an unnecessary invocation of `SftpObject.getType()` by
`refresh()`.
This invocation causes performance degradation of
`SftpFileObject.getChildren()` when `CacheStrategy.ON_RESOLVE` is in use as
this forces a call to `refresh()`, which in turn calls `getType()`, making an
additional `stat()` call to the SFTP server for each child.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 261060)
Time Spent: 10m
Remaining Estimate: 0h
> Issue creating HttpClient timeout
> -
>
> Key: VFS-619
> URL: https://issues.apache.org/jira/browse/VFS-619
> Project: Commons VFS
> Issue Type: Bug
>Reporter: Ben Xiang
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Hi,
> Recently we met an issue that the thread got stuck during the http connection
> using HttpClient. And It showed that the connection timeout was set to 0,
> which was not what we set.
> let me briefly show here how we are using VFS2:
> Create a FileSystemOptions with timeout set:
> {code}
> final FileSystemOptions fso = new FileSystemOptions();
> final HttpFileSystemConfigBuilder httpBuilder =
> HttpFileSystemConfigBuilder.getInstance();
> httpBuilder.setConnectionTimeout(fso, connectionTimeout);
> httpBuilder.setSoTimeout(fso, soTimeout);
> {code}
> Create a FileObject using FileSystemManager:
> {code}
> vfs2FileManager.resolveFile(fileLocation, fso);
> {code}
> Finally get the input stream using DefaultFileContent:
> {code}
> final InputStream instr = fileObject.getInputStream();
> {code}
> We noticed that in executeMethod() of HttpMethodDirector, line 153, it is
> setting the connection timeout using client's params. However,
> in HttpClientFactory, it's setting fileSystemOptions in connectionMgrParams,
> and the HttpClient's params would not have this value.
> So we added following 2 lines to make it work:
> In package org.apache.commons.vfs2.provider.http, HttpClientFactory, added
> line 148 and 149:
> {code}
> client.getParams().setConnectionManagerTimeout(connectionMgrParams.getConnectionTimeout());
> client.getParams().setSoTimeout(connectionMgrParams.getSoTimeout());
> {code}
> Please let me know your thought about this and if there is a patch needed, or
> is there something we are missing or doing wrong ?
> Thanks!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CSV-135) Char escape doesn't work properly with quoting
[
https://issues.apache.org/jira/browse/CSV-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb updated CSV-135:
-
Summary: Char escape doesn't work properly with quoting (was: Char escape
doesn't work)
> Char escape doesn't work properly with quoting
> --
>
> Key: CSV-135
> URL: https://issues.apache.org/jira/browse/CSV-135
> Project: Commons CSV
> Issue Type: Bug
> Components: Printer
>Affects Versions: 1.0
>Reporter: Mateusz Zakarczemny
>Priority: Major
> Fix For: Patch Needed
>
>
> Following code:
> {code}
> CSVFormat format = CSVFormat.DEFAULT
> .withRecordSeparator('\n')
> .withQuote('"')
> .withEscape('\\');
> CSVPrinter printer = new CSVPrinter(System.out, format);
> List l = new LinkedList();
> l.add("\"");
> l.add("\n");
> l.add("\\");
> printer.printRecord(l);
> {code}
> produces
> {code}
> ,"
> ","\"
> {code}
> instead of
> {code}
> "\"","\n","\\"
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [commons-vfs] DavidSeptimus opened a new pull request #65: VFS-619 Fixes performance issue with SftpFileObject.getChildren()
DavidSeptimus opened a new pull request #65: VFS-619 Fixes performance issue with SftpFileObject.getChildren() URL: https://github.com/apache/commons-vfs/pull/65 This PR removes an unnecessary invocation of `SftpObject.getType()` by `refresh()`. This invocation causes performance degradation of `SftpFileObject.getChildren()` when `CacheStrategy.ON_RESOLVE` is in use as this forces a call to `refresh()`, which in turn calls `getType()`, making an additional `stat()` call to the SFTP server for each child. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (CSV-135) Char escape doesn't work
[
https://issues.apache.org/jira/browse/CSV-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865150#comment-16865150
]
Sebb commented on CSV-135:
--
bq. This is exactly where QuoteMode comes into play: If it is NONE then it is
strictly print-with-escapes, otherwise it's some flavor of Quoting.
Yes, but the other QuoteMode settings failed to take account of embedded
escapes.
> Char escape doesn't work
>
>
> Key: CSV-135
> URL: https://issues.apache.org/jira/browse/CSV-135
> Project: Commons CSV
> Issue Type: Bug
> Components: Printer
>Affects Versions: 1.0
>Reporter: Mateusz Zakarczemny
>Priority: Major
> Fix For: Patch Needed
>
>
> Following code:
> {code}
> CSVFormat format = CSVFormat.DEFAULT
> .withRecordSeparator('\n')
> .withQuote('"')
> .withEscape('\\');
> CSVPrinter printer = new CSVPrinter(System.out, format);
> List l = new LinkedList();
> l.add("\"");
> l.add("\n");
> l.add("\\");
> printer.printRecord(l);
> {code}
> produces
> {code}
> ,"
> ","\"
> {code}
> instead of
> {code}
> "\"","\n","\\"
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CSV-135) Char escape doesn't work
[
https://issues.apache.org/jira/browse/CSV-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865149#comment-16865149
]
Sebb commented on CSV-135:
--
This fixes the problem as originally reported.
f7c2ca2 CSV-135 - Char escape doesn't work
If there are related problems, please raise a separate issue.
> Char escape doesn't work
>
>
> Key: CSV-135
> URL: https://issues.apache.org/jira/browse/CSV-135
> Project: Commons CSV
> Issue Type: Bug
> Components: Printer
>Affects Versions: 1.0
>Reporter: Mateusz Zakarczemny
>Priority: Major
> Fix For: Patch Needed
>
>
> Following code:
> {code}
> CSVFormat format = CSVFormat.DEFAULT
> .withRecordSeparator('\n')
> .withQuote('"')
> .withEscape('\\');
> CSVPrinter printer = new CSVPrinter(System.out, format);
> List l = new LinkedList();
> l.add("\"");
> l.add("\n");
> l.add("\\");
> printer.printRecord(l);
> {code}
> produces
> {code}
> ,"
> ","\"
> {code}
> instead of
> {code}
> "\"","\n","\\"
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MATH-1490) Percentile computational accuracy issue
Lingchao Chen created MATH-1490: --- Summary: Percentile computational accuracy issue Key: MATH-1490 URL: https://issues.apache.org/jira/browse/MATH-1490 Project: Commons Math Issue Type: Bug Affects Versions: 3.6.1, 3.6, 3.5, 3.4.1, 3.4 Environment: System: Linux testinglab 4.4.0-131-generic #157~14.04.1-Ubuntu Java version "1.8.0_191" Java(TM) SE Runtime Environment (build 1.8.0_191-b12) Java HotSpot(TM) 64-Bit Server VM (build 25.191-b12, mixed mode) Reporter: Lingchao Chen Attachments: BugDemo.java The percentile method works well on the older versions, e.g., the version before 3.4. However, when I update commons-math to the newer version, there produces a computational accuracy issue. There is a backward compatibility bug behind it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CSV-135) Char escape doesn't work
[
https://issues.apache.org/jira/browse/CSV-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865147#comment-16865147
]
Sebb commented on CSV-135:
--
The problem is two fold:
1) {{printWithQuotes}} does not check for embedded escapes when deciding
whether to encapsulate the value
2) it does not escape embedded escape chars in the value
> Char escape doesn't work
>
>
> Key: CSV-135
> URL: https://issues.apache.org/jira/browse/CSV-135
> Project: Commons CSV
> Issue Type: Bug
> Components: Printer
>Affects Versions: 1.0
>Reporter: Mateusz Zakarczemny
>Priority: Major
> Fix For: Patch Needed
>
>
> Following code:
> {code}
> CSVFormat format = CSVFormat.DEFAULT
> .withRecordSeparator('\n')
> .withQuote('"')
> .withEscape('\\');
> CSVPrinter printer = new CSVPrinter(System.out, format);
> List l = new LinkedList();
> l.add("\"");
> l.add("\n");
> l.add("\\");
> printer.printRecord(l);
> {code}
> produces
> {code}
> ,"
> ","\"
> {code}
> instead of
> {code}
> "\"","\n","\\"
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-698) SFTP file attributes are fetched multiple times leading to very slow directory listing
[
https://issues.apache.org/jira/browse/VFS-698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865112#comment-16865112
]
David Septimus commented on VFS-698:
This issue is cause by a call to {{getType()}} inside from {{SftpFileObject}}'s
implementation of {{FileObject.refresh()}}. This forces a {{stat}} call to the
SFTP server to refresh the instance's {{FileType}}.
Based on my understanding of the refresh process, the primary purpose of
{{refresh()}} is to clear the internal state of the {{FileObject}} instance, so
the next operation called on the instance is forced to refresh its state from
the underlying file sytstem. {{SftpFileObject.refresh()}} is the only
implementation that actually makes a file system call.
> SFTP file attributes are fetched multiple times leading to very slow
> directory listing
> --
>
> Key: VFS-698
> URL: https://issues.apache.org/jira/browse/VFS-698
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: krishnan
>Priority: Major
>
> getChildren() applied on SftpFileObject is very slow compared to JSCH
> implementation. This is because, the SftpATTRS which is readily available for
> the children after an "ls" call is again fetched for each child file since
> they are independently resolved. So if a directory contains 10 files, it
> results in 1 (ls) + 10 (stat) calls to server.
> For a folder with 100 files (AWS), it took about 35 secs instead of 1.5 secs
> to getChildren().
>
> *doListChildrenResolved:*
> {{final FileObject fo =
> getFileSystem().resolveFile(getFileSystem().getFileSystemManager()}}
> \{{ .resolveName(getName(), UriParser.encode(name), NameScope.CHILD));}}
> {{{color:#ff}((SftpFileObject)
> FileObjectUtils.getAbstractFileObject(fo)).setStat(stat.getAttrs());{color}}}
>
> The resolveFile call, creates a SftpFileObject and calls its resolve method,
> which results in getting the (stats) SftpATTRS for each child file. This stat
> is already available as part of the 'ls' call we made. The setStat call above
> (highlighted is red) is redundant, since stat for each child file is already
> fetched one at a time.
> The solution would be to avoid getting the stat for each child file after an
> 'ls' call. May be, the framework makes it difficult to do this easily.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-698) SFTP file attributes are fetched multiple times leading to very slow directory listing
[
https://issues.apache.org/jira/browse/VFS-698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865089#comment-16865089
]
David Septimus commented on VFS-698:
As far as I can tell, this is only an issue when your {{FileSystem}} is using
{{CacheStrategy.ON_RESOLVE}}. This forces the {{FileSystem}} to call
{{refresh()}} on the newly created {{SftpFileObject}} (see:
{{AbstractFileSystem.resolveFile(...)}}) and because {{attrs}} is null at the
the time of resolution, a call is made to the server in order to determine the
file's {{FileType}} (see: {{SftpFileObject.refresh()}} and
{{SftpFileObject.doGetType()}}).
> SFTP file attributes are fetched multiple times leading to very slow
> directory listing
> --
>
> Key: VFS-698
> URL: https://issues.apache.org/jira/browse/VFS-698
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: krishnan
>Priority: Major
>
> getChildren() applied on SftpFileObject is very slow compared to JSCH
> implementation. This is because, the SftpATTRS which is readily available for
> the children after an "ls" call is again fetched for each child file since
> they are independently resolved. So if a directory contains 10 files, it
> results in 1 (ls) + 10 (stat) calls to server.
> For a folder with 100 files (AWS), it took about 35 secs instead of 1.5 secs
> to getChildren().
>
> *doListChildrenResolved:*
> {{final FileObject fo =
> getFileSystem().resolveFile(getFileSystem().getFileSystemManager()}}
> \{{ .resolveName(getName(), UriParser.encode(name), NameScope.CHILD));}}
> {{{color:#ff}((SftpFileObject)
> FileObjectUtils.getAbstractFileObject(fo)).setStat(stat.getAttrs());{color}}}
>
> The resolveFile call, creates a SftpFileObject and calls its resolve method,
> which results in getting the (stats) SftpATTRS for each child file. This stat
> is already available as part of the 'ls' call we made. The setStat call above
> (highlighted is red) is redundant, since stat for each child file is already
> fetched one at a time.
> The solution would be to avoid getting the stat for each child file after an
> 'ls' call. May be, the framework makes it difficult to do this easily.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CSV-135) Char escape doesn't work
[
https://issues.apache.org/jira/browse/CSV-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865078#comment-16865078
]
Opher Shachar commented on CSV-135:
---
On the printing front
{quote}{color:#33}However, for printing, if both are specified and the
chars are different, which should take precedence?{color}
{color:#33} (Be strict in what you generate){color}
{quote}
This is *_exactly_* where {color:#14892c}*QuoteMode*{color} comes into play: If
it is *NONE* then it is strictly +_print-with-escapes_+, otherwise it's some
flavor of Quoting.
For parsing how would you parse a record such as?
|ID,Address,Image Path,Document Path
1,"3rd Lincoln boulevard\, Miami\, FL",D:\Images\Houses\ID_1.png,"D:\Property
Documents\ID 1.docx"|
> Char escape doesn't work
>
>
> Key: CSV-135
> URL: https://issues.apache.org/jira/browse/CSV-135
> Project: Commons CSV
> Issue Type: Bug
> Components: Printer
>Affects Versions: 1.0
>Reporter: Mateusz Zakarczemny
>Priority: Major
> Fix For: Patch Needed
>
>
> Following code:
> {code}
> CSVFormat format = CSVFormat.DEFAULT
> .withRecordSeparator('\n')
> .withQuote('"')
> .withEscape('\\');
> CSVPrinter printer = new CSVPrinter(System.out, format);
> List l = new LinkedList();
> l.add("\"");
> l.add("\n");
> l.add("\\");
> printer.printRecord(l);
> {code}
> produces
> {code}
> ,"
> ","\"
> {code}
> instead of
> {code}
> "\"","\n","\\"
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CSV-177) Support trimming leading and trailing blanks
[ https://issues.apache.org/jira/browse/CSV-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865067#comment-16865067 ] Sebb commented on CSV-177: -- Since found out that withTrim() affects the storage of values in CSVParser#addRecordValue > Support trimming leading and trailing blanks > > > Key: CSV-177 > URL: https://issues.apache.org/jira/browse/CSV-177 > Project: Commons CSV > Issue Type: New Feature > Components: Parser, Printer >Affects Versions: 1.2 >Reporter: Gary Gregory >Assignee: Gary Gregory >Priority: Major > Fix For: 1.3 > > > Support trimming leading and trailing blanks in the printer and parser. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (STATISTICS-17) RELEVANT INFORMATION LIST
[ https://issues.apache.org/jira/browse/STATISTICS-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben Nguyen updated STATISTICS-17: - Summary: RELEVANT INFORMATION LIST (was: CS Regression: RELEVANT INFORMATION LIST) > RELEVANT INFORMATION LIST > - > > Key: STATISTICS-17 > URL: https://issues.apache.org/jira/browse/STATISTICS-17 > Project: Apache Commons Statistics > Issue Type: Sub-task >Reporter: Ben Nguyen >Priority: Major > > *+Relevant JIRA Issues+* > * OLSMultipleLinearRegression estimates different residuals with different > order of input > ** https://issues.apache.org/jira/browse/MATH-1428 > * SimpleRegression#getSlopeConfidenceInterval recalculates t distribution on > every call > ** https://issues.apache.org/jira/browse/MATH-1441 > +*Relevant Legacy Pull Requests*+ > * [https://github.com/apache/commons-math/pull/106] > ** Related JIRA: > *** Pull request for GLSMultipleLinearRegression > *** https://issues.apache.org/jira/browse/MATH-1482 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (STATISTICS-17) RELEVANT INFORMATION LIST
[ https://issues.apache.org/jira/browse/STATISTICS-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben Nguyen updated STATISTICS-17: - Priority: Blocker (was: Major) > RELEVANT INFORMATION LIST > - > > Key: STATISTICS-17 > URL: https://issues.apache.org/jira/browse/STATISTICS-17 > Project: Apache Commons Statistics > Issue Type: Sub-task >Reporter: Ben Nguyen >Priority: Blocker > > *+Relevant JIRA Issues+* > * OLSMultipleLinearRegression estimates different residuals with different > order of input > ** https://issues.apache.org/jira/browse/MATH-1428 > * SimpleRegression#getSlopeConfidenceInterval recalculates t distribution on > every call > ** https://issues.apache.org/jira/browse/MATH-1441 > +*Relevant Legacy Pull Requests*+ > * [https://github.com/apache/commons-math/pull/106] > ** Related JIRA: > *** Pull request for GLSMultipleLinearRegression > *** https://issues.apache.org/jira/browse/MATH-1482 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (STATISTICS-17) CS Regression: RELEVANT INFORMATION LIST
Ben Nguyen created STATISTICS-17: Summary: CS Regression: RELEVANT INFORMATION LIST Key: STATISTICS-17 URL: https://issues.apache.org/jira/browse/STATISTICS-17 Project: Apache Commons Statistics Issue Type: Sub-task Reporter: Ben Nguyen *+Relevant JIRA Issues+* * OLSMultipleLinearRegression estimates different residuals with different order of input ** https://issues.apache.org/jira/browse/MATH-1428 * SimpleRegression#getSlopeConfidenceInterval recalculates t distribution on every call ** https://issues.apache.org/jira/browse/MATH-1441 +*Relevant Legacy Pull Requests*+ * [https://github.com/apache/commons-math/pull/106] ** Related JIRA: *** Pull request for GLSMultipleLinearRegression *** https://issues.apache.org/jira/browse/MATH-1482 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [commons-numbers] coveralls edited a comment on issue #48: [WIP] perform the actual migration to JUnit 5
coveralls edited a comment on issue #48: [WIP] perform the actual migration to JUnit 5 URL: https://github.com/apache/commons-numbers/pull/48#issuecomment-500176439 [](https://coveralls.io/builds/24023995) Coverage remained the same at 94.381% when pulling **b1a114f406e90b2432b6e925cfcc2497477ce339 on grimreaper:eax/simple-migrate-map** into **934be57412ff6ab9fd67f0eeeddba49895afff06 on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (VFS-698) SFTP file attributes are fetched multiple times leading to very slow directory listing
[
https://issues.apache.org/jira/browse/VFS-698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865060#comment-16865060
]
David Septimus commented on VFS-698:
I just ran into this issue myself trying to list a directory of ~200,000 files.
The call to getChildren() ran for over an hour before I killed it whereas the
underlying call to Channel.ls(...) ran for ~30 seconds for the same directory.
Due to time constraints, I went with a workaround – extending the FileObject
interface with a streamChildren() method that returns a Stream and
an SftpFileObject implementation of that method to lazily convert LsEntry
instances to SftpFileObject as needed.
> SFTP file attributes are fetched multiple times leading to very slow
> directory listing
> --
>
> Key: VFS-698
> URL: https://issues.apache.org/jira/browse/VFS-698
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: krishnan
>Priority: Major
>
> getChildren() applied on SftpFileObject is very slow compared to JSCH
> implementation. This is because, the SftpATTRS which is readily available for
> the children after an "ls" call is again fetched for each child file since
> they are independently resolved. So if a directory contains 10 files, it
> results in 1 (ls) + 10 (stat) calls to server.
> For a folder with 100 files (AWS), it took about 35 secs instead of 1.5 secs
> to getChildren().
>
> *doListChildrenResolved:*
> {{final FileObject fo =
> getFileSystem().resolveFile(getFileSystem().getFileSystemManager()}}
> \{{ .resolveName(getName(), UriParser.encode(name), NameScope.CHILD));}}
> {{{color:#ff}((SftpFileObject)
> FileObjectUtils.getAbstractFileObject(fo)).setStat(stat.getAttrs());{color}}}
>
> The resolveFile call, creates a SftpFileObject and calls its resolve method,
> which results in getting the (stats) SftpATTRS for each child file. This stat
> is already available as part of the 'ls' call we made. The setStat call above
> (highlighted is red) is redundant, since stat for each child file is already
> fetched one at a time.
> The solution would be to avoid getting the stat for each child file after an
> 'ls' call. May be, the framework makes it difficult to do this easily.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CSV-135) Char escape doesn't work
[
https://issues.apache.org/jira/browse/CSV-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865056#comment-16865056
]
Sebb commented on CSV-135:
--
On the contrary, quote and escape chars can both be specified; indeed many
formats do this.
For example ORACLE and INFORMIX_UNLOAD.
For parsing, this should not be a problem, as both and
should generate .
(Be liberal in what you accept)
However, for printing, if both are specified and the chars are different, which
should take precedence?
(Be strict in what you generate)
This currently applies to the following formats:
INFORMIX_UNLOAD, ORACLE, POSTGRESQL_TEXT
> Char escape doesn't work
>
>
> Key: CSV-135
> URL: https://issues.apache.org/jira/browse/CSV-135
> Project: Commons CSV
> Issue Type: Bug
> Components: Printer
>Affects Versions: 1.0
>Reporter: Mateusz Zakarczemny
>Priority: Major
> Fix For: Patch Needed
>
>
> Following code:
> {code}
> CSVFormat format = CSVFormat.DEFAULT
> .withRecordSeparator('\n')
> .withQuote('"')
> .withEscape('\\');
> CSVPrinter printer = new CSVPrinter(System.out, format);
> List l = new LinkedList();
> l.add("\"");
> l.add("\n");
> l.add("\\");
> printer.printRecord(l);
> {code}
> produces
> {code}
> ,"
> ","\"
> {code}
> instead of
> {code}
> "\"","\n","\\"
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [commons-numbers] coveralls edited a comment on issue #48: [WIP] perform the actual migration to JUnit 5
coveralls edited a comment on issue #48: [WIP] perform the actual migration to JUnit 5 URL: https://github.com/apache/commons-numbers/pull/48#issuecomment-500176439 [](https://coveralls.io/builds/24023244) Coverage remained the same at 94.381% when pulling **fe63782a789e31f2ffb5f93c5696a009f138a85a on grimreaper:eax/simple-migrate-map** into **934be57412ff6ab9fd67f0eeeddba49895afff06 on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Resolved] (CSV-235) WRONG Implementation for RFC4180
[ https://issues.apache.org/jira/browse/CSV-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CSV-235. -- Resolution: Fixed AFAICT the implementation is correct; see: https://github.com/apache/commons-csv/commit/c025d73d31ca9c9c467f3bad142ca62d7ebee76b If that is not your experience, please re-open with at least a test case that shows the issue you are having. > WRONG Implementation for RFC4180 > -- > > Key: CSV-235 > URL: https://issues.apache.org/jira/browse/CSV-235 > Project: Commons CSV > Issue Type: Bug > Components: Parser >Affects Versions: 1.6 >Reporter: Edward Xia >Priority: Major > > [https://tools.ietf.org/html/rfc4180#section-2] >7. If double-quotes are used to enclose fields, then a double-quote >appearing inside a field must be escaped by preceding it with >another double quote. For example: >"aaa","b""bb","ccc" > Apparently, base on a previous issue: > https://issues.apache.org/jira/browse/CSV-208, it turns out common-csv *does > not even support quote and escape to be the same character*. > RFC 4180 defines that quote and escape are both DQUOTE, however in common-csv > implementation, the default escape character is not DQUOTE, and it does not > work if changed to DQUOTE. > This means common csv is not rfc4180 compliant. > Also, I'm puzzled by the fact that someone marked CSV-208 as fixed when > nothing is fixed. Instead, it changed the behavior without documenting that > the POSTGRESQL_CSV format does not even work out of the box with the default > csv format that postgresql produces. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CSV-243) CSVFormat withTrim() and withIgnoreSurroundingSpaces() need better docs
[ https://issues.apache.org/jira/browse/CSV-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CSV-243. -- Resolution: Fixed bc64fb5 CSV-243 CSVFormat withTrim() and withIgnoreSurroundingSpaces() > CSVFormat withTrim() and withIgnoreSurroundingSpaces() need better docs > --- > > Key: CSV-243 > URL: https://issues.apache.org/jira/browse/CSV-243 > Project: Commons CSV > Issue Type: Bug >Reporter: Sebb >Priority: Major > > It looks like withIgnoreSurroundingSpaces() is a parser option and withTrim() > is a printer option. > These need better Javadoc. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CSV-243) CSVFormat withTrim() and withIgnoreSurroundingSpaces() need better docs
[ https://issues.apache.org/jira/browse/CSV-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16864992#comment-16864992 ] Sebb edited comment on CSV-243 at 6/16/19 11:22 AM: Turns out that withTrim() is used by CSVParser as well as CSVFormat#print. CSVParser#addRecord uses it to determine whether to trim the field value before storing in the recordList. was (Author: s...@apache.org): Turns out that withTrim() is used by CSVParser as well as CSVFormat#print > CSVFormat withTrim() and withIgnoreSurroundingSpaces() need better docs > --- > > Key: CSV-243 > URL: https://issues.apache.org/jira/browse/CSV-243 > Project: Commons CSV > Issue Type: Bug >Reporter: Sebb >Priority: Major > > It looks like withIgnoreSurroundingSpaces() is a parser option and withTrim() > is a printer option. > These need better Javadoc. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (CSV-243) CSVFormat withTrim() and withIgnoreSurroundingSpaces() need better docs
[ https://issues.apache.org/jira/browse/CSV-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb reopened CSV-243: -- Turns out that withTrim() is used by CSVParser as well as CSVFormat#print > CSVFormat withTrim() and withIgnoreSurroundingSpaces() need better docs > --- > > Key: CSV-243 > URL: https://issues.apache.org/jira/browse/CSV-243 > Project: Commons CSV > Issue Type: Bug >Reporter: Sebb >Priority: Major > > It looks like withIgnoreSurroundingSpaces() is a parser option and withTrim() > is a printer option. > These need better Javadoc. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [commons-configuration] sebbASF commented on issue #16: [CONFIGURATION-731] Allow user to specify the comments & separator ch…
sebbASF commented on issue #16: [CONFIGURATION-731] Allow user to specify the comments & separator ch… URL: https://github.com/apache/commons-configuration/pull/16#issuecomment-502441549 The PR was auto-closed because trunk was deleted; please re-open against master if it still applies This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-configuration] sebbASF commented on issue #15: CONFIGURATION-729: fixes inconsistency in example
sebbASF commented on issue #15: CONFIGURATION-729: fixes inconsistency in example URL: https://github.com/apache/commons-configuration/pull/15#issuecomment-502441532 The PR was auto-closed because trunk was deleted; please re-open against master if it still applies This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-configuration] sebbASF commented on issue #14: [CONFIGURATION-715/716]: Updated the User's guide to include JupIOFac…
sebbASF commented on issue #14: [CONFIGURATION-715/716]: Updated the User's guide to include JupIOFac… URL: https://github.com/apache/commons-configuration/pull/14#issuecomment-502441518 The PR was auto-closed because trunk was deleted; please re-open against master if it still applies This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-configuration] sebbASF commented on issue #11: Configuration 703
sebbASF commented on issue #11: Configuration 703 URL: https://github.com/apache/commons-configuration/pull/11#issuecomment-502441492 The PR was auto-closed because trunk was deleted; please re-open against master if it still applies This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-logging] sebbASF commented on issue #1: default methods to Log interface to prevent unnecessary payload creation
sebbASF commented on issue #1: default methods to Log interface to prevent unnecessary payload creation URL: https://github.com/apache/commons-logging/pull/1#issuecomment-502441458 The PR was auto-closed because trunk was deleted; please re-open against master if it still applies This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-jcs] sebbASF commented on issue #4: JCS-195 Update element attributes size on serialization
sebbASF commented on issue #4: JCS-195 Update element attributes size on serialization URL: https://github.com/apache/commons-jcs/pull/4#issuecomment-502441296 The PR was auto-closed because trunk was deleted; please re-open against master if it still applies This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-jcs] sebbASF commented on issue #3: JCS-193: [CDI] [JCache annotations] Set configuration more friendly.
sebbASF commented on issue #3: JCS-193: [CDI] [JCache annotations] Set configuration more friendly. URL: https://github.com/apache/commons-jcs/pull/3#issuecomment-502441252 The PR was auto-closed because trunk was deleted; please re-open against master if it still applies This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-jcs] sebbASF commented on issue #2: Javadoc Fixes
sebbASF commented on issue #2: Javadoc Fixes URL: https://github.com/apache/commons-jcs/pull/2#issuecomment-502441095 The PR was auto-closed because trunk was deleted; please re-open against master if it still applies This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-proxy] sebbASF commented on issue #1: PROXY-25 Adds various utility methods dealing with Spring proxies
sebbASF commented on issue #1: PROXY-25 Adds various utility methods dealing with Spring proxies URL: https://github.com/apache/commons-proxy/pull/1#issuecomment-502440976 The PR was auto-closed because trunk was deleted; please re-open against master if it still applies This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Work logged] (CONFIGURATION-729) inconsistency in "Quick start guide"
[
https://issues.apache.org/jira/browse/CONFIGURATION-729?focusedWorklogId=261008=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-261008
]
ASF GitHub Bot logged work on CONFIGURATION-729:
Author: ASF GitHub Bot
Created on: 16/Jun/19 10:12
Start Date: 16/Jun/19 10:12
Worklog Time Spent: 10m
Work Description: sebbASF commented on pull request #15:
CONFIGURATION-729: fixes inconsistency in example
URL: https://github.com/apache/commons-configuration/pull/15
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 261008)
Time Spent: 10m
Remaining Estimate: 0h
> inconsistency in "Quick start guide"
>
>
> Key: CONFIGURATION-729
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-729
> Project: Commons Configuration
> Issue Type: Bug
> Components: Documentation
>Affects Versions: 2.3
>Reporter: Moritz Maisel
>Priority: Trivial
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The guide states
> {quote}We assume that it is stored as {{database.properties}} in the local
> file system:
> {quote}
> but in the code example below the name _config.properties_ is used:
> {quote}Configuration config = configs.properties(new
> File("config.properties"));
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Work logged] (JCS-195) Update element attributes size on serialization
[
https://issues.apache.org/jira/browse/JCS-195?focusedWorklogId=261010=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-261010
]
ASF GitHub Bot logged work on JCS-195:
--
Author: ASF GitHub Bot
Created on: 16/Jun/19 10:12
Start Date: 16/Jun/19 10:12
Worklog Time Spent: 10m
Work Description: sebbASF commented on pull request #4: JCS-195 Update
element attributes size on serialization
URL: https://github.com/apache/commons-jcs/pull/4
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 261010)
Time Spent: 10m
Remaining Estimate: 0h
> Update element attributes size on serialization
> ---
>
> Key: JCS-195
> URL: https://issues.apache.org/jira/browse/JCS-195
> Project: Commons JCS
> Issue Type: Improvement
> Components: Composite Cache
>Affects Versions: jcs-2.2
>Reporter: quietmint
>Assignee: Thomas Vandahl
>Priority: Major
> Labels: admin-interface, beginner, documentation, easyfix,
> pull-request-available
> Fix For: jcs-3.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{ElementAttributes}} class has a field to store the size in bytes (e.g., for
> use in an admin-style page). Calculating the size is an expensive operation,
> so it makes sense to save the size whenever we serialize the element. Admin
> pages that want this data could then get a cheap approximation from the last
> time the element was serialized.
> Additionally, the javadocs say the size field is populated as -1 by default,
> but it's really 0 by default.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Work logged] (JCS-193) [JCACHE] How to configure caches used by interceptors (i.e. CacheResultInterceptor) related to JCache annotations
[
https://issues.apache.org/jira/browse/JCS-193?focusedWorklogId=261011=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-261011
]
ASF GitHub Bot logged work on JCS-193:
--
Author: ASF GitHub Bot
Created on: 16/Jun/19 10:12
Start Date: 16/Jun/19 10:12
Worklog Time Spent: 10m
Work Description: sebbASF commented on pull request #3: JCS-193: [CDI]
[JCache annotations] Set configuration more friendly.
URL: https://github.com/apache/commons-jcs/pull/3
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 261011)
Time Spent: 10m
Remaining Estimate: 0h
> [JCACHE] How to configure caches used by interceptors (i.e.
> CacheResultInterceptor) related to JCache annotations
> -
>
> Key: JCS-193
> URL: https://issues.apache.org/jira/browse/JCS-193
> Project: Commons JCS
> Issue Type: Improvement
> Components: Composite Cache
>Affects Versions: jcs-2.2
>Reporter: Ricard Nàcher Roig
>Priority: Major
> Labels: pull-request-available
> Fix For: jcs-3.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I started using JCS cache as a JCache implementation provider a few days ago
> and everything was fine until I needed to set up expiration for cached data
> or even the number of elements stored in the cache. I realized that caches
> were created with EternalPolicy so I started to figure out how to set up both
> implementation specific properties and Standard JCache ones. After a couple
> of days, I don't have a pretty idea about how to configure the caches related
> to methods annotated with JCache annotations like CacheResult, CacheRemove
> and so on.
> I mean that I already know that I can use the CacheDefaults annotation, both
> at class and method level, in order to set the name of the cache to be used.
> but another thing is to also set the CacheResolverFactory. Should I always
> set the CacheResolverFactory in the annotation in order to be able to create
> the cache using a specific set of properties? Or maybe the idea is to create
> the cache programmatically before is is needed? Anyway, It seems too much
> boilerplate to me. Maybe I am wrong but I think that we are not using the CDI
> power at all.
> please, let me know if there is better/simpler approach.
> Another thing that I cannot understand is the readConfig method of the
> JCSCachingManager class. It is loading the folder structure because it is
> loading the resources from the default uri of the provider!
> where uri is "jcs://jcache.ccf", so the path is "/". I think that this URI
> should not be used for this, maybe the uri should be something different (URI
> of the default configuration?) or just use another implementation specific
> property. Notice that adding an extra slash will look for /jcache.ccf file!
> maybe it is just a bug and there is a slash missing : "jcs:///jcache.ccf"
> {code:java}
> final Enumeration resources = loader.getResources(uri.getPath());
> {code}
>
> What about this?
> Add CachingProvider and CacheManager as beans if they are not already beans.
> Notice that this is what jcs-jcache-extras module already does!
> So as a developer I can configure my CachingProvider and even the cache
> manager already configured as beans. They will be injected where needed
> instead of being created without configuration.
> no configuration in CacheResolverFactory
> {code:java}
> public CacheResolverFactoryImpl()
> {
> provider = Caching.getCachingProvider();
> cacheManager = provider.getCacheManager(provider.getDefaultURI(),
> provider.getDefaultClassLoader());
> }
> {code}
> but in JCacheFilter class some properties are set
>
> {code:java}
> manager = provider.getCacheManager(URI.create(uri), classLoader, properties);
> {code}
> One step further into CDI should be to also provide the CacheResolverFactory
> as a bean and also the
> CacheResolverFactoryImpl could be also injected with the cacheProvider and
> CacheManager and some CompleteConfigurationResolver of something like that in
> order to avoid creating caches with a hard-coded MutableConfiguration.
> {code:java}
> public class CacheResolverFactoryImpl implements CacheResolverFactory
> {
> ...
> private Cache createCache(final String exceptionCacheName)
> {
> cacheManager.createCache(exceptionCacheName, new
>
[jira] [Work logged] (CONFIGURATION-715) PropertiesConfiguration should not trim whitespace from the property value
[
https://issues.apache.org/jira/browse/CONFIGURATION-715?focusedWorklogId=261009=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-261009
]
ASF GitHub Bot logged work on CONFIGURATION-715:
Author: ASF GitHub Bot
Created on: 16/Jun/19 10:12
Start Date: 16/Jun/19 10:12
Worklog Time Spent: 10m
Work Description: sebbASF commented on pull request #14:
[CONFIGURATION-715/716]: Updated the User's guide to include JupIOFac…
URL: https://github.com/apache/commons-configuration/pull/14
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 261009)
Time Spent: 10m
Remaining Estimate: 0h
> PropertiesConfiguration should not trim whitespace from the property value
> --
>
> Key: CONFIGURATION-715
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-715
> Project: Commons Configuration
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Patrick Schmidt
>Priority: Major
> Fix For: 2.4
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, PropertiesConfiguration will trim all trailing whitespace from
> property values. This is different from how java.util.Properties behaves. The
> Javadoc explicitly states
> {code:java}
> All remaining characters on the line become part of the associated element
> string{code}
> The responsible code is in the method _readProperty()_ of _PropertiesReader_.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [commons-proxy] sebbASF closed pull request #1: PROXY-25 Adds various utility methods dealing with Spring proxies
sebbASF closed pull request #1: PROXY-25 Adds various utility methods dealing with Spring proxies URL: https://github.com/apache/commons-proxy/pull/1 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-jcs] sebbASF closed pull request #2: Javadoc Fixes
sebbASF closed pull request #2: Javadoc Fixes URL: https://github.com/apache/commons-jcs/pull/2 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-configuration] sebbASF closed pull request #11: Configuration 703
sebbASF closed pull request #11: Configuration 703 URL: https://github.com/apache/commons-configuration/pull/11 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-configuration] sebbASF closed pull request #14: [CONFIGURATION-715/716]: Updated the User's guide to include JupIOFac…
sebbASF closed pull request #14: [CONFIGURATION-715/716]: Updated the User's guide to include JupIOFac… URL: https://github.com/apache/commons-configuration/pull/14 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-jcs] sebbASF closed pull request #4: JCS-195 Update element attributes size on serialization
sebbASF closed pull request #4: JCS-195 Update element attributes size on serialization URL: https://github.com/apache/commons-jcs/pull/4 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-configuration] sebbASF closed pull request #15: CONFIGURATION-729: fixes inconsistency in example
sebbASF closed pull request #15: CONFIGURATION-729: fixes inconsistency in example URL: https://github.com/apache/commons-configuration/pull/15 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-jcs] sebbASF closed pull request #3: JCS-193: [CDI] [JCache annotations] Set configuration more friendly.
sebbASF closed pull request #3: JCS-193: [CDI] [JCache annotations] Set configuration more friendly. URL: https://github.com/apache/commons-jcs/pull/3 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-configuration] sebbASF closed pull request #16: [CONFIGURATION-731] Allow user to specify the comments & separator ch…
sebbASF closed pull request #16: [CONFIGURATION-731] Allow user to specify the comments & separator ch… URL: https://github.com/apache/commons-configuration/pull/16 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-logging] sebbASF closed pull request #1: default methods to Log interface to prevent unnecessary payload creation
sebbASF closed pull request #1: default methods to Log interface to prevent unnecessary payload creation URL: https://github.com/apache/commons-logging/pull/1 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
