[jira] [Commented] (CLI-297) Required argument empty checking not working with equals specified long option
[
https://issues.apache.org/jira/browse/CLI-297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16908712#comment-16908712
]
Friedrich Clausen commented on CLI-297:
---
I have attempted a fix for this against the _cli-1.x_ branch; if fixes the
issue without introducing any regressions in the existing tests however I don't
know if it is what you are looking for in terms of contributions. Happy to redo
another way
{code}
diff --git a/src/java/org/apache/commons/cli/Parser.java
b/src/java/org/apache/commons/cli/Parser.java
index b8306b6..c74d8a2 100644
--- a/src/java/org/apache/commons/cli/Parser.java
+++ b/src/java/org/apache/commons/cli/Parser.java
@@ -342,6 +342,10 @@ public abstract class Parser implements CommandLineParser
{
throw new MissingArgumentException(opt);
}
+
+if (opt.getValues() != null && opt.getValue().equals("")) {
+throw new MissingArgumentException(opt);
+}
}
/**
diff --git a/src/test/org/apache/commons/cli/bug/BugCLI297Test.java
b/src/test/org/apache/commons/cli/bug/BugCLI297Test.java
new file mode 100644
index 000..e3aaa96
--- /dev/null
+++ b/src/test/org/apache/commons/cli/bug/BugCLI297Test.java
@@ -0,0 +1,35 @@
+package org.apache.commons.cli.bug;
+
+import junit.framework.TestCase;
+import org.apache.commons.cli.*;
+
+public class BugCLI297Test extends TestCase
+{
+ public void testMissingRequiredLongOptionEqualsSeparator()
+ {
+String[] args = new String[] { "--cfile=" };
+
+Options longOpt = new Options();
+longOpt.addOption( OptionBuilder.withLongOpt( "cfile" )
+.hasArg()
+.isRequired()
+.withDescription( "set the value of [c]" )
+.create( 'c' ) );
+
+try
+{
+ CommandLineParser parser = new PosixParser();
+ CommandLine cl = parser.parse(longOpt,args);
+ fail( "exception should have been thrown" );
+}
+catch (MissingArgumentException e)
+{
+ assertEquals( "Incorrect exception message", "Missing argument for
option: c", e.getMessage() );
+ assertEquals("c", e.getOption().getOpt());
+}
+catch (ParseException e)
+{
+ fail( "expected to catch MissingOptionException but got " +
e.getMessage() + " which is a " + e.getClass());
+}
+ }
+}
{code}
> Required argument empty checking not working with equals specified long option
> --
>
> Key: CLI-297
> URL: https://issues.apache.org/jira/browse/CLI-297
> Project: Commons CLI
> Issue Type: Bug
> Components: CLI-1.x
>Affects Versions: 1.4
> Environment: OS: macOS 10.14.6
> Java: Corretto-8.212.04.2 (build 1.8.0_212-b04)
>Reporter: Friedrich Clausen
>Priority: Minor
>
> When an option taking an argument is specified with a space the blank
> checking works:
> {code:none}
> $ CheckEmpty --widget-count
> org.apache.commons.cli.MissingArgumentException: Missing argument for option:
> widget-count
> {code}
> However when using the equals sign as a separator that checking does not
> seem to apply
> {code:none}
> $ CheckEmpty --widget-count=
> Received widget count of:
> {code}
> I'd expect it to throw an exception just like the space separated variety.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (CLI-297) Required argument empty checking not working with equals specified long option
[
https://issues.apache.org/jira/browse/CLI-297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Friedrich Clausen updated CLI-297:
--
Description:
When an option taking an argument is specified with a space the blank checking
works:
{code:none}
$ CheckEmpty --widget-count
org.apache.commons.cli.MissingArgumentException: Missing required option:
widget-count
{code}
However when using the equals sign as a separator that checking does not seem
to apply
{code:none}
$ CheckEmpty --widget-count=
Received widget count of:
{code}
I'd expect it to throw an exception just like the space separated variety.
was:
When an option taking an argument is specified with a space the blank checking
works:
{code:none}
$ CheckEmpty --widget-count
org.apache.commons.cli.MissingOptionException: Missing required option:
widget-count
{code}
However when using the equals sign as a separator that checking does not seem
to apply
{code:none}
$ CheckEmpty --widget-count=
Received widget count of:
{code}
I'd expect it to throw an exception just like the space separated variety.
> Required argument empty checking not working with equals specified long option
> --
>
> Key: CLI-297
> URL: https://issues.apache.org/jira/browse/CLI-297
> Project: Commons CLI
> Issue Type: Bug
> Components: CLI-1.x
>Affects Versions: 1.4
> Environment: OS: macOS 10.14.6
> Java: Corretto-8.212.04.2 (build 1.8.0_212-b04)
>Reporter: Friedrich Clausen
>Priority: Minor
>
> When an option taking an argument is specified with a space the blank
> checking works:
> {code:none}
> $ CheckEmpty --widget-count
> org.apache.commons.cli.MissingArgumentException: Missing required option:
> widget-count
> {code}
> However when using the equals sign as a separator that checking does not
> seem to apply
> {code:none}
> $ CheckEmpty --widget-count=
> Received widget count of:
> {code}
> I'd expect it to throw an exception just like the space separated variety.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (CLI-297) Required argument empty checking not working with equals specified long option
[
https://issues.apache.org/jira/browse/CLI-297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Friedrich Clausen updated CLI-297:
--
Description:
When an option taking an argument is specified with a space the blank checking
works:
{code:none}
$ CheckEmpty --widget-count
org.apache.commons.cli.MissingArgumentException: Missing argument for option:
widget-count
{code}
However when using the equals sign as a separator that checking does not seem
to apply
{code:none}
$ CheckEmpty --widget-count=
Received widget count of:
{code}
I'd expect it to throw an exception just like the space separated variety.
was:
When an option taking an argument is specified with a space the blank checking
works:
{code:none}
$ CheckEmpty --widget-count
org.apache.commons.cli.MissingArgumentException: Missing required option:
widget-count
{code}
However when using the equals sign as a separator that checking does not seem
to apply
{code:none}
$ CheckEmpty --widget-count=
Received widget count of:
{code}
I'd expect it to throw an exception just like the space separated variety.
> Required argument empty checking not working with equals specified long option
> --
>
> Key: CLI-297
> URL: https://issues.apache.org/jira/browse/CLI-297
> Project: Commons CLI
> Issue Type: Bug
> Components: CLI-1.x
>Affects Versions: 1.4
> Environment: OS: macOS 10.14.6
> Java: Corretto-8.212.04.2 (build 1.8.0_212-b04)
>Reporter: Friedrich Clausen
>Priority: Minor
>
> When an option taking an argument is specified with a space the blank
> checking works:
> {code:none}
> $ CheckEmpty --widget-count
> org.apache.commons.cli.MissingArgumentException: Missing argument for option:
> widget-count
> {code}
> However when using the equals sign as a separator that checking does not
> seem to apply
> {code:none}
> $ CheckEmpty --widget-count=
> Received widget count of:
> {code}
> I'd expect it to throw an exception just like the space separated variety.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (CLI-297) Required argument empty checking not working with equals specified long option
[
https://issues.apache.org/jira/browse/CLI-297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16908600#comment-16908600
]
Friedrich Clausen edited comment on CLI-297 at 8/16/19 1:22 AM:
This standalone test program reproduces the issue for me:
{code:java}
import org.apache.commons.cli.*;
class CheckEmpty {
public static void main(String[] args) {
Option widgetCount = Option.builder()
.longOpt("widget-count")
.hasArg()
.required()
.build();
Options options = new Options();
options.addOption(widgetCount);
CommandLineParser parser = new DefaultParser();
CommandLine commandLine;
try {
commandLine = parser.parse(options, args);
if (commandLine.hasOption("widget-count")) {
String optionArg = commandLine.getOptionValue("widget-count");
System.out.println("Received widget count of: " + optionArg);
}
} catch (ParseException e) {
System.err.println("Problem parsing args: " + e);
System.exit(1);
}
}
}
{code}
was (Author: ftclausen):
This snippet reproduces the issue for me:
{code:java}
import org.apache.commons.cli.*;
class CheckEmpty {
public static void main(String[] args) {
Option widgetCount = Option.builder()
.longOpt("widget-count")
.hasArg()
.required()
.build();
Options options = new Options();
options.addOption(widgetCount);
CommandLineParser parser = new DefaultParser();
CommandLine commandLine;
try {
commandLine = parser.parse(options, args);
if (commandLine.hasOption("widget-count")) {
String optionArg = commandLine.getOptionValue("widget-count");
System.out.println("Received widget count of: " + optionArg);
}
} catch (ParseException e) {
System.err.println("Problem parsing args: " + e);
System.exit(1);
}
}
}
{code}
> Required argument empty checking not working with equals specified long option
> --
>
> Key: CLI-297
> URL: https://issues.apache.org/jira/browse/CLI-297
> Project: Commons CLI
> Issue Type: Bug
> Components: CLI-1.x
>Affects Versions: 1.4
> Environment: OS: macOS 10.14.6
> Java: Corretto-8.212.04.2 (build 1.8.0_212-b04)
>Reporter: Friedrich Clausen
>Priority: Minor
>
> When an option taking an argument is specified with a space the blank
> checking works:
> {code:none}
> $ CheckEmpty --widget-count
> org.apache.commons.cli.MissingOptionException: Missing required option:
> widget-count
> {code}
> However when using the equals sign as a separator that checking does not
> seem to apply
> {code:none}
> $ CheckEmpty --widget-count=
> Received widget count of:
> {code}
> I'd expect it to throw an exception just like the space separated variety.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (CLI-297) Required argument empty checking not working with equals specified long option
[
https://issues.apache.org/jira/browse/CLI-297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16908600#comment-16908600
]
Friedrich Clausen commented on CLI-297:
---
This snippet reproduces the issue for me:
{code:java}
import org.apache.commons.cli.*;
class CheckEmpty {
public static void main(String[] args) {
Option widgetCount = Option.builder()
.longOpt("widget-count")
.hasArg()
.required()
.build();
Options options = new Options();
options.addOption(widgetCount);
CommandLineParser parser = new DefaultParser();
CommandLine commandLine;
try {
commandLine = parser.parse(options, args);
if (commandLine.hasOption("widget-count")) {
String optionArg = commandLine.getOptionValue("widget-count");
System.out.println("Received widget count of: " + optionArg);
}
} catch (ParseException e) {
System.err.println("Problem parsing args: " + e);
System.exit(1);
}
}
}
{code}
> Required argument empty checking not working with equals specified long option
> --
>
> Key: CLI-297
> URL: https://issues.apache.org/jira/browse/CLI-297
> Project: Commons CLI
> Issue Type: Bug
> Components: CLI-1.x
>Affects Versions: 1.4
> Environment: OS: macOS 10.14.6
> Java: Corretto-8.212.04.2 (build 1.8.0_212-b04)
>Reporter: Friedrich Clausen
>Priority: Minor
>
> When an option taking an argument is specified with a space the blank
> checking works:
> {code:none}
> $ CheckEmpty --widget-count
> org.apache.commons.cli.MissingOptionException: Missing required option:
> widget-count
> {code}
> However when using the equals sign as a separator that checking does not
> seem to apply
> {code:none}
> $ CheckEmpty --widget-count=
> Received widget count of:
> {code}
> I'd expect it to throw an exception just like the space separated variety.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (CLI-297) Required argument empty checking not working with equals specified long option
[
https://issues.apache.org/jira/browse/CLI-297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16908600#comment-16908600
]
Friedrich Clausen edited comment on CLI-297 at 8/16/19 1:22 AM:
This standalone test program reproduces the issue for me:
{code:java}
import org.apache.commons.cli.*;
class CheckEmpty {
public static void main(String[] args) {
Option widgetCount = Option.builder()
.longOpt("widget-count")
.hasArg()
.required()
.build();
Options options = new Options();
options.addOption(widgetCount);
CommandLineParser parser = new DefaultParser();
CommandLine commandLine;
try {
commandLine = parser.parse(options, args);
if (commandLine.hasOption("widget-count")) {
String optionArg = commandLine.getOptionValue("widget-count");
System.out.println("Received widget count of: " + optionArg);
}
} catch (ParseException e) {
System.err.println("Problem parsing args: " + e);
System.exit(1);
}
}
}
{code}
was (Author: ftclausen):
This standalone test program reproduces the issue for me:
{code:java}
import org.apache.commons.cli.*;
class CheckEmpty {
public static void main(String[] args) {
Option widgetCount = Option.builder()
.longOpt("widget-count")
.hasArg()
.required()
.build();
Options options = new Options();
options.addOption(widgetCount);
CommandLineParser parser = new DefaultParser();
CommandLine commandLine;
try {
commandLine = parser.parse(options, args);
if (commandLine.hasOption("widget-count")) {
String optionArg = commandLine.getOptionValue("widget-count");
System.out.println("Received widget count of: " + optionArg);
}
} catch (ParseException e) {
System.err.println("Problem parsing args: " + e);
System.exit(1);
}
}
}
{code}
> Required argument empty checking not working with equals specified long option
> --
>
> Key: CLI-297
> URL: https://issues.apache.org/jira/browse/CLI-297
> Project: Commons CLI
> Issue Type: Bug
> Components: CLI-1.x
>Affects Versions: 1.4
> Environment: OS: macOS 10.14.6
> Java: Corretto-8.212.04.2 (build 1.8.0_212-b04)
>Reporter: Friedrich Clausen
>Priority: Minor
>
> When an option taking an argument is specified with a space the blank
> checking works:
> {code:none}
> $ CheckEmpty --widget-count
> org.apache.commons.cli.MissingOptionException: Missing required option:
> widget-count
> {code}
> However when using the equals sign as a separator that checking does not
> seem to apply
> {code:none}
> $ CheckEmpty --widget-count=
> Received widget count of:
> {code}
> I'd expect it to throw an exception just like the space separated variety.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (CLI-297) Required argument empty checking not working with equals specified long option
Friedrich Clausen created CLI-297:
-
Summary: Required argument empty checking not working with equals
specified long option
Key: CLI-297
URL: https://issues.apache.org/jira/browse/CLI-297
Project: Commons CLI
Issue Type: Bug
Components: CLI-1.x
Affects Versions: 1.4
Environment: OS: macOS 10.14.6
Java: Corretto-8.212.04.2 (build 1.8.0_212-b04)
Reporter: Friedrich Clausen
When an option taking an argument is specified with a space the blank checking
works:
{code:none}
$ CheckEmpty --widget-count
org.apache.commons.cli.MissingOptionException: Missing required option:
widget-count
{code}
However when using the equals sign as a separator that checking does not seem
to apply
{code:none}
$ CheckEmpty --widget-count=
Received widget count of:
{code}
I'd expect it to throw an exception just like the space separated variety.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (VFS-500) VFSClassLoader.findResources missing
[ https://issues.apache.org/jira/browse/VFS-500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated VFS-500: - Fix Version/s: (was: 2.4.1) 2.4.2 > VFSClassLoader.findResources missing > > > Key: VFS-500 > URL: https://issues.apache.org/jira/browse/VFS-500 > Project: Commons VFS > Issue Type: New Feature >Affects Versions: 2.0 >Reporter: Bernd Eckenfels >Assignee: Bernd Eckenfels >Priority: Minor > Fix For: 2.4.2 > > Attachments: vfs-500-gg.diff > > > the VFSClassLoader.findResources(String) method is a dummy implementation > returning an empty Enumeration. > I have a working implementation and will support the patch for it, this is > the JIRA to track it. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (VFS-596) Add User and Password to Socks 5 Proxy Configuration
[ https://issues.apache.org/jira/browse/VFS-596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated VFS-596: - Fix Version/s: (was: 2.4.1) 2.4.2 > Add User and Password to Socks 5 Proxy Configuration > > > Key: VFS-596 > URL: https://issues.apache.org/jira/browse/VFS-596 > Project: Commons VFS > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: Simon Eiersbrock >Priority: Major > Fix For: 2.4.2 > > Attachments: COMMONSVFS-21-AddUserAndPasswordToSocks5Proxy.patch > > > The library jcraft.jsch can handle a socks 5 proxy with user and password, > but the Commons VFS2 API does not route the user and password to this > library. > I created a patch to enable Commons VFS to use a socks 5 proxy with user and > password. It is attached to this issue. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (VFS-586) Add more ways to specify alternate HDFS configuration information
[ https://issues.apache.org/jira/browse/VFS-586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated VFS-586: - Fix Version/s: (was: 2.4.1) 2.4.2 > Add more ways to specify alternate HDFS configuration information > - > > Key: VFS-586 > URL: https://issues.apache.org/jira/browse/VFS-586 > Project: Commons VFS > Issue Type: Improvement >Affects Versions: 2.1 > Environment: All >Reporter: Roger Whitcomb >Priority: Minor > Fix For: 2.4.2 > > Attachments: hdfs-config-2.diffs > > > In trying to resolve some customer issues we were experiencing, it was > necessary to specify some alternate HDFS configuration information from some > places other than resources in the current classpath, plus needing to specify > multiple configurations (such as a local copy of "core-site.xml" and > "hdfs-site.xml"). To accomplish this I have proposed some changes to > HdfsFileSystemConfigBuilder.java and HdfsFileSystem.java to be able to > specify alternate configurations from all the possible sources (as defined in > org.apache.hadoop.fs.Configuration), namely from a named resource, from a > local file Path, from an InputStream and from another Configuration object. > For resource names and local files, multiple entries are allowed so that > multiple configuration files can be specified as needed. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (VFS-651) SftpFileSystem Should not switch to root directory when not absolutely needed
[
https://issues.apache.org/jira/browse/VFS-651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated VFS-651:
-
Fix Version/s: (was: 2.4.1)
2.4.2
> SftpFileSystem Should not switch to root directory when not absolutely needed
> -
>
> Key: VFS-651
> URL: https://issues.apache.org/jira/browse/VFS-651
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Syed Aqeel Ashiq
>Priority: Major
> Fix For: 2.4.2
>
>
> Consider a user X only has read/write access to let's say /sftp and /sftp/abc
> directory on a sftp server. And default directory for user is /sftp
> In this case, we have to set userDirIsRoot to false, and thus vfs will try to
> switch to root directory, which will fail due to lack of read permission.
> Consider following code:
> {code:java}
> public void uploadFile(String localFilePath) throws FileSystemException {
>
> FileSystemManager manager = VFS.getManager();
> FileObject localFile = manager.resolveFile(localFilePath);
> FileSystemOptions opts = new FileSystemOptions();
> SftpFileSystemConfigBuilder.getInstance().setUserDirIsRoot(opts, false);
> // I set it to false,
> // because user default dir is /sftp and it is obviously not root
> directory.
> // As a workaround, If I set it to true, it will work after also tweaking
> with
> // the file path while resolving a file, but semantics will be wrong,
> since
> // the user directory is not root.
> SftpFileSystemConfigBuilder.getInstance().setTimeout(opts, 9);
> String remoteFilePath =
> "sftp://myuser:myp...@myurl.sftpexample.com/sftp/abc/abc.txt";;
> // Exception at the following line
> FileObject remoteFile = manager.resolveFile(remoteFilePath, opts);
> // Exception at the line above line. Because this line tries to switch to
> // root directory of sftp file system, whichfails due to lack of read
> // permission on root directory. Switching to root directory is not
> // needed here at all. This is bug, although it works in most scenarios,
> // since most of times, permissions are available.
> remoteFile.copyFrom(localFile, Selectors.SELECT_SELF);
> }
> {code}
> This is the underlying code responsible in
> {code:java}
> org.apache.commons.vfs.provider.sftp.SftpFileSystem
> {code}
> :
> {code:java}
> Boolean userDirIsRoot =
> SftpFileSystemConfigBuilder.getInstance().getUserDirIsRoot(getFileSystemOptions());
> String workingDirectory = getRootName().getPath();
> if (workingDirectory != null && (userDirIsRoot == null ||
> !userDirIsRoot.booleanValue())) {
> try {
> channel.cd(workingDirectory);
> } catch (SftpException e) {
> throw new
> FileSystemException("vfs.provider.sftp/change-work-directory.error",
> workingDirectory);
> }
> }{code}
> It purposelessly switches to root directory of filesystem. There is a fair
> use-case that root directory doesn't have read access.
> *Possible Fix:* It should not switch to root directory, rather it should
> switch to actual final directory. This approach would be the safest. E.g. if
> the needed directory is '/sftp/abc' then it can switch to that directory in
> above code, rather than switching to root.
> Please also see related SO question:
> https://stackoverflow.com/questions/48709971/why-apache-vfs-sftp-tries-to-switch-to-root-directory-even-when-not-needed
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (VFS-298) FTP: Exception is thrown when renaming a file
[ https://issues.apache.org/jira/browse/VFS-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated VFS-298: - Fix Version/s: (was: 2.4.1) 2.4.2 > FTP: Exception is thrown when renaming a file > - > > Key: VFS-298 > URL: https://issues.apache.org/jira/browse/VFS-298 > Project: Commons VFS > Issue Type: Bug >Affects Versions: Nightly Builds >Reporter: Kirill Safonov >Priority: Major > Labels: PatchAvailable > Fix For: 2.4.2 > > Attachments: VFS-298-patch.txt > > > java.lang.UnsupportedOperationException > at java.util.Collections$UnmodifiableMap.remove(Collections.java:1289) > at > org.apache.commons.vfs.provider.ftp.FtpFileObject.onChildrenChanged(FtpFileObject.java:288) > at > org.apache.commons.vfs.provider.AbstractFileObject.childrenChanged(AbstractFileObject.java:1612) > at > org.apache.commons.vfs.provider.AbstractFileObject.notifyParent(AbstractFileObject.java:1633) > at > org.apache.commons.vfs.provider.AbstractFileObject.handleDelete(AbstractFileObject.java:1558) > at > org.apache.commons.vfs.provider.AbstractFileObject.moveTo(AbstractFileObject.java:1078) > FtpFileObject.children may be an EMPTY_FTP_FILE_MAP if the last ls() returned > empty collection. This is the case for the move > untitled36/src/com/test/Base.as -> untitled36/src/Base.as: > > CWD /opt/lampp/htdocs/ftp_root > 250 Directory successfully changed. > > RNFR untitled36/src/com/test/Base.as > 350 Ready for RNTO. > > RNTO untitled36/src/Base.as > 250 Rename successful. > > PWD > 257 "/opt/lampp/htdocs/ftp_root" > > CWD untitled36/src/com/test > 250 Directory successfully changed. > > PORT 192,168,0,112,51,217 > 200 PORT command successful. Consider using PASV. > > LIST > 150 Here comes the directory listing. > 226 Directory send OK. > (LIST returned no children) -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (VFS-600) HttpProviderTestCase#testHttp405 is repeatedly failling
[
https://issues.apache.org/jira/browse/VFS-600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated VFS-600:
-
Fix Version/s: (was: 2.4.1)
2.4.2
> HttpProviderTestCase#testHttp405 is repeatedly failling
>
>
> Key: VFS-600
> URL: https://issues.apache.org/jira/browse/VFS-600
> Project: Commons VFS
> Issue Type: Task
>Affects Versions: 2.1
>Reporter: Josh Elser
>Priority: Minor
> Fix For: 2.4.2
>
>
> testHttp405 is repeatedly failing with the below message:
> {noformat}
> testHttp405(org.apache.commons.vfs2.provider.http.test.HttpProviderTestCase)
> Time elapsed: 0.558 sec <<< ERROR!
> org.apache.commons.vfs2.FileSystemException: Could not determine the size of
> "http://www.w3schools.com/webservices/tempconvert.asmx?action=WSDL"; because
> it is not a file.
> at
> org.apache.commons.vfs2.provider.DefaultFileContent.getSize(DefaultFileContent.java:135)
> at
> org.apache.commons.vfs2.provider.http.test.HttpProviderTestCase.testHttp405(HttpProviderTestCase.java:208)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.commons.vfs2.test.AbstractProviderTestCase.runTest(AbstractProviderTestCase.java:218)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:252)
> at junit.framework.TestSuite.run(TestSuite.java:247)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23)
> at
> org.apache.commons.vfs2.test.AbstractTestSuite$1.protect(AbstractTestSuite.java:149)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at
> org.apache.commons.vfs2.test.AbstractTestSuite.run(AbstractTestSuite.java:154)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {noformat}
> It seems like that URL is now throwing an HTTP 404?
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (VFS-613) doIsWriteable() is not implemented for FtpFileObject
[ https://issues.apache.org/jira/browse/VFS-613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated VFS-613: - Fix Version/s: (was: 2.4.1) 2.4.2 > doIsWriteable() is not implemented for FtpFileObject > > > Key: VFS-613 > URL: https://issues.apache.org/jira/browse/VFS-613 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Johannes Wollnik >Priority: Major > Fix For: 2.4.2 > > > The doIsWriteable() method is not implemented for FtpFileObject and so the > isWritable() method returns always true no matter of the actual permissions. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (CONFIGURATION-753) Handling of interpolation is inconsistent
[
https://issues.apache.org/jira/browse/CONFIGURATION-753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated CONFIGURATION-753:
-
Summary: Handling of interpolation is inconsistent (was: Handling of
interpolation is inconsistant)
> Handling of interpolation is inconsistent
> -
>
> Key: CONFIGURATION-753
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-753
> Project: Commons Configuration
> Issue Type: Bug
> Components: Interpolation
>Affects Versions: 2.5
> Environment: Java 8, Configurations2 2.5
>Reporter: Peter
>Priority: Major
> Attachments: test.properties
>
>
> If a key is repeated in a configuration and then used in an interpolation
> elsewhere, the behaviour is inconsistent. There are other tickets/discussions
> about whether it should just pick the first value or not, but I don't think
> it should do both.
> {code:java|title=/tmp/test.properties}
> abc = hello
> abc = world
> foo.one = ${abc}
> foo.two = prefix ${abc} suffix
> {code}
> {code:java|title=Demo.java (main)}
> Parameters params = new Parameters();
> FileBasedConfigurationBuilder builder = new
> FileBasedConfigurationBuilder(PropertiesConfiguration.class)
> .configure(params.fileBased()
> .setFileName("/tmp/test.properties")
> );
> try {
> FileBasedConfiguration config = builder.getConfiguration();
> System.out.println(config.getString("foo.one"));
> System.out.println(config.getString("foo.two"));
> } catch (ConfigurationException cex) {
> // pass
> }
> {code}
> The output from the above is
> {noformat}
> hello
> prefix [hello, world] suffix
> {noformat}
> In the first case, only the first value is being matched, in the second both
> values (and [, ]) are used.
> I'd expect the output to either be
> {noformat:title=First value only}
> hello
> prefix hello suffix
> {noformat}
> or
> {noformat:title=Both values used}
> [hello, world]
> prefix [hello, world] suffix
> {noformat}
> I can work around whichever style is chosen but think it'd be much more
> intuitive if both cases were handled the same.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (CONFIGURATION-753) Handling of interpolation is inconsistant
[
https://issues.apache.org/jira/browse/CONFIGURATION-753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter updated CONFIGURATION-753:
Description:
If a key is repeated in a configuration and then used in an interpolation
elsewhere, the behaviour is inconsistent. There are other tickets/discussions
about whether it should just pick the first value or not, but I don't think it
should do both.
{code:java|title=/tmp/test.properties}
abc = hello
abc = world
foo.one = ${abc}
foo.two = prefix ${abc} suffix
{code}
{code:java|title=Demo.java (main)}
Parameters params = new Parameters();
FileBasedConfigurationBuilder builder = new
FileBasedConfigurationBuilder(PropertiesConfiguration.class)
.configure(params.fileBased()
.setFileName("/tmp/test.properties")
);
try {
FileBasedConfiguration config = builder.getConfiguration();
System.out.println(config.getString("foo.one"));
System.out.println(config.getString("foo.two"));
} catch (ConfigurationException cex) {
// pass
}
{code}
The output from the above is
{noformat}
hello
prefix [hello, world] suffix
{noformat}
In the first case, only the first value is being matched, in the second both
values (and [, ]) are used.
I'd expect the output to either be
{noformat:title=First value only}
hello
prefix hello suffix
{noformat}
or
{noformat:title=Both values used}
[hello, world]
prefix [hello, world] suffix
{noformat}
I can work around whichever style is chosen but think it'd be much more
intuitive if both cases were handled the same.
was:
If a key is repeated in a configuration and then used in an interpolation else
where, the behaviour is inconsistent. There are other tickets/discussions about
whether it should just pick the first value or not, but I don't think it should
do both.
{code:title=/tmp/test.properties}
abc = hello
abc = world
foo.one = ${abc}
foo.two = prefix ${abc} suffix
{code}
{code:title=Demo.java (main)}
Parameters params = new Parameters();
FileBasedConfigurationBuilder builder = new
FileBasedConfigurationBuilder(PropertiesConfiguration.class)
.configure(params.fileBased()
.setFileName("/tmp/test.properties")
);
try {
FileBasedConfiguration config = builder.getConfiguration();
System.out.println(config.getString("foo.one"));
System.out.println(config.getString("foo.two"));
} catch (ConfigurationException cex) {
// pass
}
{code}
The output from the above is
{noformat}
hello
prefix [hello, world] suffix
{noformat}
In the first case, only the first value is being matched, in the second both
values (and [, ]) are used.
I'd expect the output to either be
{noformat:title=First value only}
hello
prefix hello suffix
{noformat}
or
{noformat:title=Both values used}
[hello, world]
prefix [hello, world] suffix
{noformat}
I can work around whichever style is chosen but think it'd be much more
intuitive if both cases were handled the same.
> Handling of interpolation is inconsistant
> -
>
> Key: CONFIGURATION-753
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-753
> Project: Commons Configuration
> Issue Type: Bug
> Components: Interpolation
>Affects Versions: 2.5
> Environment: Java 8, Configurations2 2.5
>Reporter: Peter
>Priority: Major
> Attachments: test.properties
>
>
> If a key is repeated in a configuration and then used in an interpolation
> elsewhere, the behaviour is inconsistent. There are other tickets/discussions
> about whether it should just pick the first value or not, but I don't think
> it should do both.
> {code:java|title=/tmp/test.properties}
> abc = hello
> abc = world
> foo.one = ${abc}
> foo.two = prefix ${abc} suffix
> {code}
> {code:java|title=Demo.java (main)}
> Parameters params = new Parameters();
> FileBasedConfigurationBuilder builder = new
> FileBasedConfigurationBuilder(PropertiesConfiguration.class)
> .configure(params.fileBased()
> .setFileName("/tmp/test.properties")
> );
> try {
> FileBasedConfiguration config = builder.getConfiguration();
> System.out.println(config.getString("foo.one"));
> System.out.println(config.getString("foo.two"));
> } catch (ConfigurationException cex) {
> // pass
> }
> {code}
> The output from the above is
> {noformat}
> hello
> prefix [hello, world] suffix
> {noformat}
> In the first case, only the first value is being matched, in the second both
> values (and [, ]) are used.
> I'd expect the output to either be
> {noformat:title=First value only}
> hello
> prefix hello suffix
> {noformat}
> or
> {noformat:title=Both values used}
> [hello, world]
> prefix [hello, world] suffix
> {noformat}
> I can work around whichever style is chosen but think it'd be much more
> intuitive if both cases were handled the same.
--
This message was sent by Atla
[jira] [Created] (CONFIGURATION-753) Handling of interpolation is inconsistant
Peter created CONFIGURATION-753:
---
Summary: Handling of interpolation is inconsistant
Key: CONFIGURATION-753
URL: https://issues.apache.org/jira/browse/CONFIGURATION-753
Project: Commons Configuration
Issue Type: Bug
Components: Interpolation
Affects Versions: 2.5
Environment: Java 8, Configurations2 2.5
Reporter: Peter
Attachments: test.properties
If a key is repeated in a configuration and then used in an interpolation else
where, the behaviour is inconsistent. There are other tickets/discussions about
whether it should just pick the first value or not, but I don't think it should
do both.
{code:title=/tmp/test.properties}
abc = hello
abc = world
foo.one = ${abc}
foo.two = prefix ${abc} suffix
{code}
{code:title=Demo.java (main)}
Parameters params = new Parameters();
FileBasedConfigurationBuilder builder = new
FileBasedConfigurationBuilder(PropertiesConfiguration.class)
.configure(params.fileBased()
.setFileName("/tmp/test.properties")
);
try {
FileBasedConfiguration config = builder.getConfiguration();
System.out.println(config.getString("foo.one"));
System.out.println(config.getString("foo.two"));
} catch (ConfigurationException cex) {
// pass
}
{code}
The output from the above is
{noformat}
hello
prefix [hello, world] suffix
{noformat}
In the first case, only the first value is being matched, in the second both
values (and [, ]) are used.
I'd expect the output to either be
{noformat:title=First value only}
hello
prefix hello suffix
{noformat}
or
{noformat:title=Both values used}
[hello, world]
prefix [hello, world] suffix
{noformat}
I can work around whichever style is chosen but think it'd be much more
intuitive if both cases were handled the same.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Closed] (GEOMETRY-59) unexpected output from PolyhedronsSet::checkPoint
[ https://issues.apache.org/jira/browse/GEOMETRY-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dirk Bonekämper closed GEOMETRY-59. --- works > unexpected output from PolyhedronsSet::checkPoint > - > > Key: GEOMETRY-59 > URL: https://issues.apache.org/jira/browse/GEOMETRY-59 > Project: Apache Commons Geometry > Issue Type: Bug > Components: Euclidean 3D >Reporter: Dirk Bonekämper >Priority: Major > Labels: pull-request-available > Attachments: InsideProblemTest.java > > Time Spent: 0.5h > Remaining Estimate: 0h > > In my project I'm working with 3D Regions modeled as prisms. The base > polygons are mostly concave. I got wrong results and boiled it down to the > attached unit test. It creates a prism with a concave base. A point that is > above the prism gets classified as INSIDE. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (GEOMETRY-59) unexpected output from PolyhedronsSet::checkPoint
[ https://issues.apache.org/jira/browse/GEOMETRY-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dirk Bonekämper resolved GEOMETRY-59. - Resolution: Fixed Using PolyhedronSet now works as expected, providing correct inside/intersection information. > unexpected output from PolyhedronsSet::checkPoint > - > > Key: GEOMETRY-59 > URL: https://issues.apache.org/jira/browse/GEOMETRY-59 > Project: Apache Commons Geometry > Issue Type: Bug > Components: Euclidean 3D >Reporter: Dirk Bonekämper >Priority: Major > Labels: pull-request-available > Attachments: InsideProblemTest.java > > Time Spent: 0.5h > Remaining Estimate: 0h > > In my project I'm working with 3D Regions modeled as prisms. The base > polygons are mostly concave. I got wrong results and boiled it down to the > attached unit test. It creates a prism with a concave base. A point that is > above the prism gets classified as INSIDE. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (GEOMETRY-59) unexpected output from PolyhedronsSet::checkPoint
[ https://issues.apache.org/jira/browse/GEOMETRY-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16908228#comment-16908228 ] Dirk Bonekämper commented on GEOMETRY-59: - Of course. Thanks again for the good work. > unexpected output from PolyhedronsSet::checkPoint > - > > Key: GEOMETRY-59 > URL: https://issues.apache.org/jira/browse/GEOMETRY-59 > Project: Apache Commons Geometry > Issue Type: Bug > Components: Euclidean 3D >Reporter: Dirk Bonekämper >Priority: Major > Labels: pull-request-available > Attachments: InsideProblemTest.java > > Time Spent: 0.5h > Remaining Estimate: 0h > > In my project I'm working with 3D Regions modeled as prisms. The base > polygons are mostly concave. I got wrong results and boiled it down to the > attached unit test. It creates a prism with a concave base. A point that is > above the prism gets classified as INSIDE. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (GEOMETRY-59) unexpected output from PolyhedronsSet::checkPoint
[ https://issues.apache.org/jira/browse/GEOMETRY-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16908197#comment-16908197 ] Matt Juntunen commented on GEOMETRY-59: --- Are you able to close this, [~bonastos]? > unexpected output from PolyhedronsSet::checkPoint > - > > Key: GEOMETRY-59 > URL: https://issues.apache.org/jira/browse/GEOMETRY-59 > Project: Apache Commons Geometry > Issue Type: Bug > Components: Euclidean 3D >Reporter: Dirk Bonekämper >Priority: Major > Labels: pull-request-available > Attachments: InsideProblemTest.java > > Time Spent: 0.5h > Remaining Estimate: 0h > > In my project I'm working with 3D Regions modeled as prisms. The base > polygons are mostly concave. I got wrong results and boiled it down to the > attached unit test. It creates a prism with a concave base. A point that is > above the prism gets classified as INSIDE. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16908196#comment-16908196
]
Matt Juntunen commented on GEOMETRY-32:
---
The euclidean module is now done!! I've removed all of the old classes from the
euclidean project. The old core partitioning classes are still required by the
spherical module so I just moved them from core to spherical for the time
being. That means that all of the modules except for spherical are in their
final states from my point of view and are ready for review on my draft PR
(https://github.com/apache/commons-geometry/pull/34). I will start work soon on
converting the spherical module over.
> BSPTree Updates
> ---
>
> Key: GEOMETRY-32
> URL: https://issues.apache.org/jira/browse/GEOMETRY-32
> Project: Apache Commons Geometry
> Issue Type: Improvement
> Components: core
>Reporter: Matt Juntunen
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The following updates should be made to the BSPTree class:
> - add an {{isLeaf()}} method to replace all of the {{node.getCut() == null}}
> expressions
> - add unit tests
> _Edit [2019-02-17]:_
> Additional goals:
> - Refactor the API to split the idea of a general BSPTree and a BSPTree used
> for defining in/out regions. This could result in a BSPTree interface and a
> RegionBSPTree interface. The goal here is to allow end-users to create their
> own extensions of these classes and specialize them for their own
> applications (for example, to implement spatial sorting or other algorithms).
> This will be one of the only planned extension points in the library.
> - Make the API easier to use and extend and reduce the necessity of casting
> (especially unchecked casting) as much as possible.
> - Add the idea of convex subhyperplanes to allow for more efficient tree
> construction.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[GitHub] [commons-collections] liuhaozzu commented on issue #81: Add lambdas function to provide default values in MapUtils
liuhaozzu commented on issue #81: Add lambdas function to provide default values in MapUtils URL: https://github.com/apache/commons-collections/pull/81#issuecomment-521622595 Get it. Thank you! Liuhao 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] (CODEC-259) Broken direct java.nio.ByteBuffer support in org.apache.commons.codec.binary.Hex
[
https://issues.apache.org/jira/browse/CODEC-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16908002#comment-16908002
]
James Howe commented on CODEC-259:
--
Surely this should solve all {{ByteBuffer}} implementation issues?
{code:java}
protected static char[] encodeHex(final ByteBuffer data, final char[] toDigits)
{
byte[] bytes = new byte[data.capacity()];
data.get(bytes, 0, data.capacity());
return encodeHex(bytes, toDigits);
}
{code}
Arguably it should also change (or additional methods added) to consume a
buffer properly, obeying position and limit.
{code:java}
protected static char[] encodeHex(final ByteBuffer data, final char[] toDigits)
{
byte[] bytes = new byte[data.remaining()];
data.get(bytes);
return encodeHex(bytes, toDigits);
}
{code}
> Broken direct java.nio.ByteBuffer support in
> org.apache.commons.codec.binary.Hex
>
>
> Key: CODEC-259
> URL: https://issues.apache.org/jira/browse/CODEC-259
> Project: Commons Codec
> Issue Type: Bug
>Affects Versions: 1.11, 1.12
>Reporter: Tomas Shestakov
>Priority: Major
> Fix For: 1.14
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> java.nio.ByteBuffer support in org.apache.commons.codec.binary.Hex does not
> work properly for direct ByteBuffer created by ByteBuffer.allocateDirect
> method and for heap ByteBuffers which arrayOffset() or byteBuffer.position()
> greater than zero or byteBuffer.remaining() is not equal
> byteBuffer.array().{color:#660e7a}length{color}:
> This test will produce java.lang.UnsupportedOperationException
> {code:java}
> @Test
> public void testEncodeHexByteBufferEmpty() {
> assertTrue(Arrays.equals(new char[0],
> Hex.encodeHex(ByteBuffer.allocateDirect(0;
> }
> {code}
> This one will fail
> {code:java}
> @Test
> public void testEncodeHexByteBufferHelloWorldLowerCaseHex() {
> final ByteBuffer b = ByteBuffer.wrap(StringUtils.getBytesUtf8("[Hello
> World]"), 1, 11);
> final String expected = "48656c6c6f20576f726c64";
> char[] actual;
> actual = Hex.encodeHex(b);
> assertEquals(expected, new String(actual));
> actual = Hex.encodeHex(b, true);
> assertEquals(expected, new String(actual));
> actual = Hex.encodeHex(b, false);
> assertFalse(expected.equals(new String(actual)));
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (CODEC-261) Unable to encode read-only ByteBuffer
James Howe created CODEC-261:
Summary: Unable to encode read-only ByteBuffer
Key: CODEC-261
URL: https://issues.apache.org/jira/browse/CODEC-261
Project: Commons Codec
Issue Type: Bug
Affects Versions: 1.13
Reporter: James Howe
A read-only array-backed {{ByteBuffer}} fails to encode, because the backing
array is not accessible.
{code:java}
Hex.encodeHex(ByteBuffer.wrap(new byte[]{1}).asReadOnlyBuffer())
{code}
{noformat}
java.nio.ReadOnlyBufferException
at java.nio.ByteBuffer.array(ByteBuffer.java:996)
at org.apache.commons.codec.binary.Hex.encodeHex(Hex.java:213)
at org.apache.commons.codec.binary.Hex.encodeHex(Hex.java:172)
at org.apache.commons.codec.binary.Hex.encodeHex(Hex.java:140)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (BEANUTILS-501) Very simple getter not found
[
https://issues.apache.org/jira/browse/BEANUTILS-501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16907995#comment-16907995
]
Melloware commented on BEANUTILS-501:
-
I agree with you, unfortunately i don't think there is any way to give a better
message as to WHY it can't reach getShortName. So yes you can probably close
this issue. Thanks!
> Very simple getter not found
>
>
> Key: BEANUTILS-501
> URL: https://issues.apache.org/jira/browse/BEANUTILS-501
> Project: Commons BeanUtils
> Issue Type: Bug
> Components: Bean / Property Utils
>Affects Versions: 1.9.3
>Reporter: Daniel Süpke
>Priority: Major
>
> Hi,
> I'm hopefully not missing something very simple, but shouldn't this be
> working?
> {code:java}
> @Test
> public void getStringWithVarsTest() {
> Serializable entity = new Serializable() {
> private String shortName = "foo";
> public String getShortName() {
> return shortName;
> }
> };
> try {
> PropertyUtils.getProperty(entity, "shortName");
> }
> catch (Exception e) {
> e.printStackTrace();
> }
> }
> {code}
> java.lang.NoSuchMethodException: Property 'shortName' has no getter method in
> class 'class com.wesustain.hera.util.LocalizerTest$1'
> at
> org.apache.commons.beanutils.PropertyUtilsBean.getSimpleProperty(PropertyUtilsBean.java:1274)
> at
> org.apache.commons.beanutils.PropertyUtilsBean.getNestedProperty(PropertyUtilsBean.java:808)
> at
> org.apache.commons.beanutils.PropertyUtilsBean.getProperty(PropertyUtilsBean.java:884)
> at
> org.apache.commons.beanutils.PropertyUtils.getProperty(PropertyUtils.java:464)
> at
> com.wesustain.hera.util.LocalizerTest.getStringWithVarsTest(LocalizerTest.java:61)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (BEANUTILS-501) Very simple getter not found
[
https://issues.apache.org/jira/browse/BEANUTILS-501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16907936#comment-16907936
]
Daniel Süpke commented on BEANUTILS-501:
Yes I understand (thanks for the reply!), I just meant that this is not clear
from the Exception itself. Of course it is technically correct, but the context
you and Dave provided are not given within this Exception. However, I'm not
sure if there is a way to actually detect this specific context and give more
meaningful feedback. If it's not possible I agree that this issue should be
closed.
> Very simple getter not found
>
>
> Key: BEANUTILS-501
> URL: https://issues.apache.org/jira/browse/BEANUTILS-501
> Project: Commons BeanUtils
> Issue Type: Bug
> Components: Bean / Property Utils
>Affects Versions: 1.9.3
>Reporter: Daniel Süpke
>Priority: Major
>
> Hi,
> I'm hopefully not missing something very simple, but shouldn't this be
> working?
> {code:java}
> @Test
> public void getStringWithVarsTest() {
> Serializable entity = new Serializable() {
> private String shortName = "foo";
> public String getShortName() {
> return shortName;
> }
> };
> try {
> PropertyUtils.getProperty(entity, "shortName");
> }
> catch (Exception e) {
> e.printStackTrace();
> }
> }
> {code}
> java.lang.NoSuchMethodException: Property 'shortName' has no getter method in
> class 'class com.wesustain.hera.util.LocalizerTest$1'
> at
> org.apache.commons.beanutils.PropertyUtilsBean.getSimpleProperty(PropertyUtilsBean.java:1274)
> at
> org.apache.commons.beanutils.PropertyUtilsBean.getNestedProperty(PropertyUtilsBean.java:808)
> at
> org.apache.commons.beanutils.PropertyUtilsBean.getProperty(PropertyUtilsBean.java:884)
> at
> org.apache.commons.beanutils.PropertyUtils.getProperty(PropertyUtils.java:464)
> at
> com.wesustain.hera.util.LocalizerTest.getStringWithVarsTest(LocalizerTest.java:61)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[GitHub] [commons-io] coveralls commented on issue #93: Control flow issues
coveralls commented on issue #93: Control flow issues URL: https://github.com/apache/commons-io/pull/93#issuecomment-521549507 [](https://coveralls.io/builds/25148780) Coverage decreased (-0.004%) to 89.239% when pulling **6a7cff08fd7696596ffc77ab0d9dc1c5d3898a2d on Mixpa:master** into **c126bdd5161a103cdd4718552d92e2b9153df70b 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
