date:20070524


[ 
https://issues.apache.org/jira/browse/CONFIGURATION-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498512
 ] 

Emmanuel Bourg commented on CONFIGURATION-273:
--

Just curious, what is the use case for this feature ? The one I see is to save 
a PropertiesConfiguration as a standard Properties file to be read by another 
application not using Commons Configuration.

This can be achieved with ConfigurationConverter.getProperties(config), it 
performs the interpolation of the variables :

PropertiesConfiguration config = new 
PropertiesConfiguration(conf.properties);
Properties props = ConfigurationConverter.getProperties(config);
FileOutputStream out = new FileOutputStream(conf2.properties)
props.save(out, null);
out.close();



 Saving with interpolation
 -

 Key: CONFIGURATION-273
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-273
 Project: Commons Configuration
  Issue Type: New Feature
Affects Versions: 1.4
Reporter: Daniel Adrian

 It will be very nice if you'll add the ability to save a configuration file 
 with the interpolation data.
 so if my config file is :
 my_home=127.0.0.1
 my_place=Is ${my_home}
 when I save the configuration (let's say with save(true)) it will look like
 my_home=127.0.0.1
 my_place=Is 127.0.0.1
 Thank you!

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (CLI-71) [cli] A weakness of parser


[ 
https://issues.apache.org/jira/browse/CLI-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498526
 ] 

Henri Yandell commented on CLI-71:
--

Another option, which is relatively similar, is to clear the values list before 
each parse. It breaks much the same other tests.

The tests that break are the ones where a parser parses the same option 
multiple times. ie) My clearing out of the undesirably persistant data is too 
deep, it needs to be higher.

 [cli] A weakness of parser
 --

 Key: CLI-71
 URL: https://issues.apache.org/jira/browse/CLI-71
 Project: Commons CLI
  Issue Type: Bug
  Components: CLI-1.x
 Environment: Operating System: other
 Platform: All
Reporter: Amro Al-Akkad
 Fix For: 1.1

 Attachments: BugCLI71Test.java, BugCLI71Test.java, 
 CLI-71-badfix.patch, TestCommonsCLI.java


 I found a weakness of Jakarta Commons CLI and want to explain it with a simple
 example: 
 Our program provides 2 options: 
 1.-a or --algo name: The -a option requires an argument.
 2.-k or --key value: The -k option requires an argument too.
 a)
 If you pass the following command line arguments everything will be ok:
 -a Caesar -k A
 After evaluation:
 • Caesar is the parameter of the -a option and
 • A is the parameter of the -k option.
 b)
 However an org.apache.commons.cli.MissingArgumentException: no argument for:k 
 is
 thrown if you pass the following input:
 -a Caesar -k a
 The Parser assumes that the argument a after the -k option, is the -a option
 missing the hyphen. At the end of this description there is Java code for
 executing this problem.
 Information:
 The handling of this command line 
 -a Caesar -k a 
 works in Getopt without any problem:
 • Caesar is the parameter of the -a option and
 • a of the -k option.
 After parsing a valid option Getopt always takes the next (available) command
 line argument as the option's parameter if the option requires an argument -
 means if you pass to the command line 
 -k -a Caesar
 After evaluation:
 • a is the parameter of the -k option
 • the Caesar argument is just ignored
 If the option's parameter (value) represents an optional argument the next
 argument is not required, if it represents a valid option - means if you pass 
 to
 the command line 
 -k -a Caesar
 After evaluation:
 • Caesar is the parameter of the -a option
 • k option is set without a parameter - in this case a default value 
 makes sense.
 Last but not least here is the code snippet for the CLI Test:
 import org.apache.commons.cli.CommandLine;
 import org.apache.commons.cli.CommandLineParser;
 import org.apache.commons.cli.Option;
 import org.apache.commons.cli.Options;
 import org.apache.commons.cli.ParseException;
 import org.apache.commons.cli.PosixParser;
 public class TestCommonsCLI {
   /**
* @param args
*/
   public static void main(String[] args) {
   
   Options options = new Options();
   
   Option algorithm = new Option(a , algo, true, the 
 algorithm which it to
 perform executing);
   algorithm.setArgName(algorithm name);
   options.addOption(algorithm);
   
   Option key = new Option(k , key, true, the key the setted 
 algorithm uses
 to process);
   algorithm.setArgName(value);
   options.addOption(key);
   
   CommandLineParser parser = new PosixParser();
   
try {
   CommandLine line = parser.parse( options, args);
   
   if(line.hasOption('a')){
   System.out.println(algo: + line.getOptionValue( a 
 ));
   }
   
   if(line.hasOption('k')){
   System.out.println(key:  + line.getOptionValue('k'));
   }
   
   
   } catch (ParseException e) {
   // TODO Auto-generated catch block
   e.printStackTrace();
   }
   }
 }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (CLI-71) [cli] A weakness of parser


 [ 
https://issues.apache.org/jira/browse/CLI-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Henri Yandell updated CLI-71:
-

Attachment: CLI-71-fix.patch

Attaching a fix for this issue. It clears the Option classes in the Options 
class before parsing. 

Opinions are very much desired, I'm not sure what side-effects this might have; 
it seems to me that it is not an intended API to be able to say:

options.getOption(a).getValues()

rather than going via the CommandLine; so I don't think there is anything bad 
with this.

Leaving open for the moment.

 [cli] A weakness of parser
 --

 Key: CLI-71
 URL: https://issues.apache.org/jira/browse/CLI-71
 Project: Commons CLI
  Issue Type: Bug
  Components: CLI-1.x
 Environment: Operating System: other
 Platform: All
Reporter: Amro Al-Akkad
 Fix For: 1.1

 Attachments: BugCLI71Test.java, BugCLI71Test.java, 
 CLI-71-badfix.patch, CLI-71-fix.patch, TestCommonsCLI.java


 I found a weakness of Jakarta Commons CLI and want to explain it with a simple
 example: 
 Our program provides 2 options: 
 1.-a or --algo name: The -a option requires an argument.
 2.-k or --key value: The -k option requires an argument too.
 a)
 If you pass the following command line arguments everything will be ok:
 -a Caesar -k A
 After evaluation:
 • Caesar is the parameter of the -a option and
 • A is the parameter of the -k option.
 b)
 However an org.apache.commons.cli.MissingArgumentException: no argument for:k 
 is
 thrown if you pass the following input:
 -a Caesar -k a
 The Parser assumes that the argument a after the -k option, is the -a option
 missing the hyphen. At the end of this description there is Java code for
 executing this problem.
 Information:
 The handling of this command line 
 -a Caesar -k a 
 works in Getopt without any problem:
 • Caesar is the parameter of the -a option and
 • a of the -k option.
 After parsing a valid option Getopt always takes the next (available) command
 line argument as the option's parameter if the option requires an argument -
 means if you pass to the command line 
 -k -a Caesar
 After evaluation:
 • a is the parameter of the -k option
 • the Caesar argument is just ignored
 If the option's parameter (value) represents an optional argument the next
 argument is not required, if it represents a valid option - means if you pass 
 to
 the command line 
 -k -a Caesar
 After evaluation:
 • Caesar is the parameter of the -a option
 • k option is set without a parameter - in this case a default value 
 makes sense.
 Last but not least here is the code snippet for the CLI Test:
 import org.apache.commons.cli.CommandLine;
 import org.apache.commons.cli.CommandLineParser;
 import org.apache.commons.cli.Option;
 import org.apache.commons.cli.Options;
 import org.apache.commons.cli.ParseException;
 import org.apache.commons.cli.PosixParser;
 public class TestCommonsCLI {
   /**
* @param args
*/
   public static void main(String[] args) {
   
   Options options = new Options();
   
   Option algorithm = new Option(a , algo, true, the 
 algorithm which it to
 perform executing);
   algorithm.setArgName(algorithm name);
   options.addOption(algorithm);
   
   Option key = new Option(k , key, true, the key the setted 
 algorithm uses
 to process);
   algorithm.setArgName(value);
   options.addOption(key);
   
   CommandLineParser parser = new PosixParser();
   
try {
   CommandLine line = parser.parse( options, args);
   
   if(line.hasOption('a')){
   System.out.println(algo: + line.getOptionValue( a 
 ));
   }
   
   if(line.hasOption('k')){
   System.out.println(key:  + line.getOptionValue('k'));
   }
   
   
   } catch (ParseException e) {
   // TODO Auto-generated catch block
   e.printStackTrace();
   }
   }
 }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (NET-161) TFTP TFTPClient.sendFile() just doesen't work

2007-05-24 Thread Peter Schmid (JIRA)

TFTP TFTPClient.sendFile() just doesen't work
-

 Key: NET-161
 URL: https://issues.apache.org/jira/browse/NET-161
 Project: Commons Net
  Issue Type: Bug
Affects Versions: 1.4
 Environment: Win xp, all java versions tested.
Reporter: Peter Schmid


sendFile() in TFTP sendFile() method does not work. It does not causes an error.
Looks like there is a bug in the communication.
I testet it with a sniffer. 
1. write request looks ok
2. aknowlege from server 
3. aknowlege from server
4. aknowlege from server
and so on.
I replaced the lib with version 1.1 and it works now.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (CLI-71) [cli] A weakness of parser


[ 
https://issues.apache.org/jira/browse/CLI-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498581
 ] 

Brian Egge commented on CLI-71:
---

I went down the clone route for quite a while, as this seemed to be the 
reasonable approach.  After implementing clone and equals in several classes, I 
got everything working except for this test case:

public void test15046() throws Exception {
CommandLineParser parser = new PosixParser();
final String[] CLI_ARGS = new String[] {-z, c};
Option option = new Option(z, timezone, true, 
   affected option);
Options cliOptions = new Options();
cliOptions.addOption(option);
parser.parse(cliOptions, CLI_ARGS);

//now add conflicting option
cliOptions.addOption(c, conflict, true, conflict option);
CommandLine line = parser.parse(cliOptions, CLI_ARGS);
assertEquals( option.getValue(), c );
assertTrue( !line.hasOption(c) );
}

The gist of it is, the class has a reference to the option is passes into 
parse.  It then checks this exact same reference for it's value.  If parse 
clones the option, the code doesn't see the value show up.

I know I've written code like this in the past, so changing the behavior would 
break some existing code.  In 2.0, we can have immutable objects and not have 
to worry about these messy mutable type, but for this case, I think the best 
option is for parse to reset all the values.  Here's the proposed fix.  I'll 
also attach this, and the test case as an ASF safe patch.

Index: src/java/org/apache/commons/cli/Parser.java
===
--- src/java/org/apache/commons/cli/Parser.java (revision 541143)
+++ src/java/org/apache/commons/cli/Parser.java (working copy)
@@ -131,6 +131,10 @@
 throws ParseException
 {
 // initialise members
+for (Iterator it = options.helpOptions().iterator(); it.hasNext();) {
+Option opt = (Option) it.next();
+opt.clear();
+}
 this.options = options;
 requiredOptions = options.getRequiredOptions();
 cmd = new CommandLine();



 [cli] A weakness of parser
 --

 Key: CLI-71
 URL: https://issues.apache.org/jira/browse/CLI-71
 Project: Commons CLI
  Issue Type: Bug
  Components: CLI-1.x
 Environment: Operating System: other
 Platform: All
Reporter: Amro Al-Akkad
 Fix For: 1.1

 Attachments: BugCLI71Test.java, BugCLI71Test.java, 
 CLI-71-badfix.patch, CLI-71-fix.patch, TestCommonsCLI.java


 I found a weakness of Jakarta Commons CLI and want to explain it with a simple
 example: 
 Our program provides 2 options: 
 1.-a or --algo name: The -a option requires an argument.
 2.-k or --key value: The -k option requires an argument too.
 a)
 If you pass the following command line arguments everything will be ok:
 -a Caesar -k A
 After evaluation:
 • Caesar is the parameter of the -a option and
 • A is the parameter of the -k option.
 b)
 However an org.apache.commons.cli.MissingArgumentException: no argument for:k 
 is
 thrown if you pass the following input:
 -a Caesar -k a
 The Parser assumes that the argument a after the -k option, is the -a option
 missing the hyphen. At the end of this description there is Java code for
 executing this problem.
 Information:
 The handling of this command line 
 -a Caesar -k a 
 works in Getopt without any problem:
 • Caesar is the parameter of the -a option and
 • a of the -k option.
 After parsing a valid option Getopt always takes the next (available) command
 line argument as the option's parameter if the option requires an argument -
 means if you pass to the command line 
 -k -a Caesar
 After evaluation:
 • a is the parameter of the -k option
 • the Caesar argument is just ignored
 If the option's parameter (value) represents an optional argument the next
 argument is not required, if it represents a valid option - means if you pass 
 to
 the command line 
 -k -a Caesar
 After evaluation:
 • Caesar is the parameter of the -a option
 • k option is set without a parameter - in this case a default value 
 makes sense.
 Last but not least here is the code snippet for the CLI Test:
 import org.apache.commons.cli.CommandLine;
 import org.apache.commons.cli.CommandLineParser;
 import org.apache.commons.cli.Option;
 import org.apache.commons.cli.Options;
 import org.apache.commons.cli.ParseException;
 import org.apache.commons.cli.PosixParser;
 public class TestCommonsCLI {
   /**
* @param args
*/
   public static void main(String[] args) {
   
   Options options = new Options();
   
   Option algorithm = new Option(a ,

[jira] Updated: (CLI-71) [cli] A weakness of parser


 [ 
https://issues.apache.org/jira/browse/CLI-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brian Egge updated CLI-71:
--

Attachment: Cloneable.patch

Here's all the work done for the clone able solution.  If we later decide to go 
down this route, this is the patch to apply.

 [cli] A weakness of parser
 --

 Key: CLI-71
 URL: https://issues.apache.org/jira/browse/CLI-71
 Project: Commons CLI
  Issue Type: Bug
  Components: CLI-1.x
 Environment: Operating System: other
 Platform: All
Reporter: Amro Al-Akkad
 Fix For: 1.1

 Attachments: BugCLI71Test.java, BugCLI71Test.java, 
 CLI-71-badfix.patch, CLI-71-fix.patch, Cloneable.patch, TestCommonsCLI.java


 I found a weakness of Jakarta Commons CLI and want to explain it with a simple
 example: 
 Our program provides 2 options: 
 1.-a or --algo name: The -a option requires an argument.
 2.-k or --key value: The -k option requires an argument too.
 a)
 If you pass the following command line arguments everything will be ok:
 -a Caesar -k A
 After evaluation:
 • Caesar is the parameter of the -a option and
 • A is the parameter of the -k option.
 b)
 However an org.apache.commons.cli.MissingArgumentException: no argument for:k 
 is
 thrown if you pass the following input:
 -a Caesar -k a
 The Parser assumes that the argument a after the -k option, is the -a option
 missing the hyphen. At the end of this description there is Java code for
 executing this problem.
 Information:
 The handling of this command line 
 -a Caesar -k a 
 works in Getopt without any problem:
 • Caesar is the parameter of the -a option and
 • a of the -k option.
 After parsing a valid option Getopt always takes the next (available) command
 line argument as the option's parameter if the option requires an argument -
 means if you pass to the command line 
 -k -a Caesar
 After evaluation:
 • a is the parameter of the -k option
 • the Caesar argument is just ignored
 If the option's parameter (value) represents an optional argument the next
 argument is not required, if it represents a valid option - means if you pass 
 to
 the command line 
 -k -a Caesar
 After evaluation:
 • Caesar is the parameter of the -a option
 • k option is set without a parameter - in this case a default value 
 makes sense.
 Last but not least here is the code snippet for the CLI Test:
 import org.apache.commons.cli.CommandLine;
 import org.apache.commons.cli.CommandLineParser;
 import org.apache.commons.cli.Option;
 import org.apache.commons.cli.Options;
 import org.apache.commons.cli.ParseException;
 import org.apache.commons.cli.PosixParser;
 public class TestCommonsCLI {
   /**
* @param args
*/
   public static void main(String[] args) {
   
   Options options = new Options();
   
   Option algorithm = new Option(a , algo, true, the 
 algorithm which it to
 perform executing);
   algorithm.setArgName(algorithm name);
   options.addOption(algorithm);
   
   Option key = new Option(k , key, true, the key the setted 
 algorithm uses
 to process);
   algorithm.setArgName(value);
   options.addOption(key);
   
   CommandLineParser parser = new PosixParser();
   
try {
   CommandLine line = parser.parse( options, args);
   
   if(line.hasOption('a')){
   System.out.println(algo: + line.getOptionValue( a 
 ));
   }
   
   if(line.hasOption('k')){
   System.out.println(key:  + line.getOptionValue('k'));
   }
   
   
   } catch (ParseException e) {
   // TODO Auto-generated catch block
   e.printStackTrace();
   }
   }
 }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (LANG-336) Finally start using generics.

Finally start using generics.
-

 Key: LANG-336
 URL: https://issues.apache.org/jira/browse/LANG-336
 Project: Commons Lang
  Issue Type: Improvement
Affects Versions: 2.3
Reporter: Hendrik Maryns


It is obvious that the Jakarta  project is reluctant in starting to use the 
'new' (how old is it by now?) generics feature of Java.  Nevertheless some 
other people would like to see it incorporated in the commons projects.

I adapted commons Lang to usee generics.  Took me about an afternoon.  Would be 
nice if something is done with it, except for only me using it in my projects.

Some stuff will have to be changed to conform to guidelines and stuff.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (CLI-71) [cli] A weakness of parser


 [ 
https://issues.apache.org/jira/browse/CLI-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brian Egge updated CLI-71:
--

Attachment: CLI71_resetvalues.patch

This is the minimal patch and tests.  This uses the method of reset any values 
when parse is called.  I included Henri's test case, as to make this single 
patch complete.

 [cli] A weakness of parser
 --

 Key: CLI-71
 URL: https://issues.apache.org/jira/browse/CLI-71
 Project: Commons CLI
  Issue Type: Bug
  Components: CLI-1.x
 Environment: Operating System: other
 Platform: All
Reporter: Amro Al-Akkad
 Fix For: 1.1

 Attachments: BugCLI71Test.java, BugCLI71Test.java, 
 CLI-71-badfix.patch, CLI-71-fix.patch, CLI71_resetvalues.patch, 
 Cloneable.patch, TestCommonsCLI.java


 I found a weakness of Jakarta Commons CLI and want to explain it with a simple
 example: 
 Our program provides 2 options: 
 1.-a or --algo name: The -a option requires an argument.
 2.-k or --key value: The -k option requires an argument too.
 a)
 If you pass the following command line arguments everything will be ok:
 -a Caesar -k A
 After evaluation:
 • Caesar is the parameter of the -a option and
 • A is the parameter of the -k option.
 b)
 However an org.apache.commons.cli.MissingArgumentException: no argument for:k 
 is
 thrown if you pass the following input:
 -a Caesar -k a
 The Parser assumes that the argument a after the -k option, is the -a option
 missing the hyphen. At the end of this description there is Java code for
 executing this problem.
 Information:
 The handling of this command line 
 -a Caesar -k a 
 works in Getopt without any problem:
 • Caesar is the parameter of the -a option and
 • a of the -k option.
 After parsing a valid option Getopt always takes the next (available) command
 line argument as the option's parameter if the option requires an argument -
 means if you pass to the command line 
 -k -a Caesar
 After evaluation:
 • a is the parameter of the -k option
 • the Caesar argument is just ignored
 If the option's parameter (value) represents an optional argument the next
 argument is not required, if it represents a valid option - means if you pass 
 to
 the command line 
 -k -a Caesar
 After evaluation:
 • Caesar is the parameter of the -a option
 • k option is set without a parameter - in this case a default value 
 makes sense.
 Last but not least here is the code snippet for the CLI Test:
 import org.apache.commons.cli.CommandLine;
 import org.apache.commons.cli.CommandLineParser;
 import org.apache.commons.cli.Option;
 import org.apache.commons.cli.Options;
 import org.apache.commons.cli.ParseException;
 import org.apache.commons.cli.PosixParser;
 public class TestCommonsCLI {
   /**
* @param args
*/
   public static void main(String[] args) {
   
   Options options = new Options();
   
   Option algorithm = new Option(a , algo, true, the 
 algorithm which it to
 perform executing);
   algorithm.setArgName(algorithm name);
   options.addOption(algorithm);
   
   Option key = new Option(k , key, true, the key the setted 
 algorithm uses
 to process);
   algorithm.setArgName(value);
   options.addOption(key);
   
   CommandLineParser parser = new PosixParser();
   
try {
   CommandLine line = parser.parse( options, args);
   
   if(line.hasOption('a')){
   System.out.println(algo: + line.getOptionValue( a 
 ));
   }
   
   if(line.hasOption('k')){
   System.out.println(key:  + line.getOptionValue('k'));
   }
   
   
   } catch (ParseException e) {
   // TODO Auto-generated catch block
   e.printStackTrace();
   }
   }
 }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (CLI-71) [cli] A weakness of parser


[ 
https://issues.apache.org/jira/browse/CLI-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498586
 ] 

Brian Egge commented on CLI-71:
---

Sorry Henri - I didn't see the work you did on this issue a few hours ago 
before I attached my comments and files.  Looks like we came to the same 
conclusion though.

 [cli] A weakness of parser
 --

 Key: CLI-71
 URL: https://issues.apache.org/jira/browse/CLI-71
 Project: Commons CLI
  Issue Type: Bug
  Components: CLI-1.x
 Environment: Operating System: other
 Platform: All
Reporter: Amro Al-Akkad
 Fix For: 1.1

 Attachments: BugCLI71Test.java, BugCLI71Test.java, 
 CLI-71-badfix.patch, CLI-71-fix.patch, CLI71_resetvalues.patch, 
 Cloneable.patch, TestCommonsCLI.java


 I found a weakness of Jakarta Commons CLI and want to explain it with a simple
 example: 
 Our program provides 2 options: 
 1.-a or --algo name: The -a option requires an argument.
 2.-k or --key value: The -k option requires an argument too.
 a)
 If you pass the following command line arguments everything will be ok:
 -a Caesar -k A
 After evaluation:
 • Caesar is the parameter of the -a option and
 • A is the parameter of the -k option.
 b)
 However an org.apache.commons.cli.MissingArgumentException: no argument for:k 
 is
 thrown if you pass the following input:
 -a Caesar -k a
 The Parser assumes that the argument a after the -k option, is the -a option
 missing the hyphen. At the end of this description there is Java code for
 executing this problem.
 Information:
 The handling of this command line 
 -a Caesar -k a 
 works in Getopt without any problem:
 • Caesar is the parameter of the -a option and
 • a of the -k option.
 After parsing a valid option Getopt always takes the next (available) command
 line argument as the option's parameter if the option requires an argument -
 means if you pass to the command line 
 -k -a Caesar
 After evaluation:
 • a is the parameter of the -k option
 • the Caesar argument is just ignored
 If the option's parameter (value) represents an optional argument the next
 argument is not required, if it represents a valid option - means if you pass 
 to
 the command line 
 -k -a Caesar
 After evaluation:
 • Caesar is the parameter of the -a option
 • k option is set without a parameter - in this case a default value 
 makes sense.
 Last but not least here is the code snippet for the CLI Test:
 import org.apache.commons.cli.CommandLine;
 import org.apache.commons.cli.CommandLineParser;
 import org.apache.commons.cli.Option;
 import org.apache.commons.cli.Options;
 import org.apache.commons.cli.ParseException;
 import org.apache.commons.cli.PosixParser;
 public class TestCommonsCLI {
   /**
* @param args
*/
   public static void main(String[] args) {
   
   Options options = new Options();
   
   Option algorithm = new Option(a , algo, true, the 
 algorithm which it to
 perform executing);
   algorithm.setArgName(algorithm name);
   options.addOption(algorithm);
   
   Option key = new Option(k , key, true, the key the setted 
 algorithm uses
 to process);
   algorithm.setArgName(value);
   options.addOption(key);
   
   CommandLineParser parser = new PosixParser();
   
try {
   CommandLine line = parser.parse( options, args);
   
   if(line.hasOption('a')){
   System.out.println(algo: + line.getOptionValue( a 
 ));
   }
   
   if(line.hasOption('k')){
   System.out.println(key:  + line.getOptionValue('k'));
   }
   
   
   } catch (ParseException e) {
   // TODO Auto-generated catch block
   e.printStackTrace();
   }
   }
 }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (LANG-336) Finally start using generics.


 [ 
https://issues.apache.org/jira/browse/LANG-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hendrik Maryns updated LANG-336:


Attachment: commons-lang-2.3-sources-generic.tar.gz

All source files, zipped.

One file is not entirely done: CompareToBuilder.  Some more thought has to go 
into this one.

 Finally start using generics.
 -

 Key: LANG-336
 URL: https://issues.apache.org/jira/browse/LANG-336
 Project: Commons Lang
  Issue Type: Improvement
Affects Versions: 2.3
Reporter: Hendrik Maryns
 Attachments: commons-lang-2.3-sources-generic.tar.gz, lang.patch


 It is obvious that the Jakarta  project is reluctant in starting to use the 
 'new' (how old is it by now?) generics feature of Java.  Nevertheless some 
 other people would like to see it incorporated in the commons projects.
 I adapted commons Lang to usee generics.  Took me about an afternoon.  Would 
 be nice if something is done with it, except for only me using it in my 
 projects.
 Some stuff will have to be changed to conform to guidelines and stuff.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (LANG-336) Finally start using generics.


 [ 
https://issues.apache.org/jira/browse/LANG-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hendrik Maryns updated LANG-336:


Attachment: lang.patch

The same stuff, but in form of a patch.

 Finally start using generics.
 -

 Key: LANG-336
 URL: https://issues.apache.org/jira/browse/LANG-336
 Project: Commons Lang
  Issue Type: Improvement
Affects Versions: 2.3
Reporter: Hendrik Maryns
 Attachments: commons-lang-2.3-sources-generic.tar.gz, lang.patch


 It is obvious that the Jakarta  project is reluctant in starting to use the 
 'new' (how old is it by now?) generics feature of Java.  Nevertheless some 
 other people would like to see it incorporated in the commons projects.
 I adapted commons Lang to usee generics.  Took me about an afternoon.  Would 
 be nice if something is done with it, except for only me using it in my 
 projects.
 Some stuff will have to be changed to conform to guidelines and stuff.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r541270 - in /jakarta/commons/proper/configuration/trunk: src/java/org/apache/commons/configuration/ src/test/org/apache/commons/configuration/ xdocs/

2007-05-24 Thread ebourg

Author: ebourg
Date: Thu May 24 04:31:25 2007
New Revision: 541270

URL: http://svn.apache.org/viewvc?view=revrev=541270
Log:
Fixed PropertiesConfiguration.save() to avoid escaping the list delimiter if it 
has been disabled (CONFIGURATION-269)

Added:

jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/ConfigurationAssert.java
Modified:

jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/PropertiesConfiguration.java

jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/PropertiesConfigurationLayout.java

jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestPropertiesConfiguration.java
jakarta/commons/proper/configuration/trunk/xdocs/changes.xml

Modified: 
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/PropertiesConfiguration.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/PropertiesConfiguration.java?view=diffrev=541270r1=541269r2=541270
==
--- 
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/PropertiesConfiguration.java
 (original)
+++ 
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/PropertiesConfiguration.java
 Thu May 24 04:31:25 2007
@@ -930,9 +930,12 @@
  */
 private String escapeValue(Object value)
 {
-String v = StringEscapeUtils.escapeJava(String.valueOf(value));
-return StringUtils.replace(v, String.valueOf(delimiter), \\
-+ delimiter);
+String escapedValue = 
StringEscapeUtils.escapeJava(String.valueOf(value));
+if (delimiter != 0)
+{
+escapedValue = StringUtils.replace(escapedValue, 
String.valueOf(delimiter), \\ + delimiter);
+}
+return escapedValue;
 }
 
 /**

Modified: 
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/PropertiesConfigurationLayout.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/PropertiesConfigurationLayout.java?view=diffrev=541270r1=541269r2=541270
==
--- 
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/PropertiesConfigurationLayout.java
 (original)
+++ 
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/PropertiesConfigurationLayout.java
 Thu May 24 04:31:25 2007
@@ -348,7 +348,8 @@
  * Sets the quot;force single linequot; flag. If this flag is set, all
  * properties with multiple values are written on single lines. This mode
  * provides more compatibility with codejava.lang.Properties/code,
- * which cannot deal with multiple definitions of a single property.
+ * which cannot deal with multiple definitions of a single property. This
+ * mode has no effect if the list delimiter parsing is disabled.
  *
  * @param f the force single line flag
  */
@@ -442,8 +443,8 @@
 {
 try
 {
-PropertiesConfiguration.PropertiesWriter writer = new 
PropertiesConfiguration.PropertiesWriter(
-out, getConfiguration().getListDelimiter());
+char delimiter = getConfiguration().isDelimiterParsingDisabled() ? 
0 : getConfiguration().getListDelimiter();
+PropertiesConfiguration.PropertiesWriter writer = new 
PropertiesConfiguration.PropertiesWriter(out, delimiter);
 if (headerComment != null)
 {
 writer.writeln(getCanonicalHeaderComment(true));
@@ -469,8 +470,8 @@
 }
 
 // Output the property and its value
-writer.writeProperty(key, getConfiguration().getProperty(
-key), isForceSingleLine() || isSingleLine(key));
+boolean singleLine = (isForceSingleLine() || 
isSingleLine(key))  !getConfiguration().isDelimiterParsingDisabled();
+writer.writeProperty(key, 
getConfiguration().getProperty(key), singleLine);
 }
 }
 writer.flush();

Added: 
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/ConfigurationAssert.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/ConfigurationAssert.java?view=autorev=541270
==
--- 
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/ConfigurationAssert.java
 (added)
+++

[jira] Resolved: (CONFIGURATION-269) PropertiesConfiguration.save() generates superfluous escaping character when delimiter parsing is disabled


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Bourg resolved CONFIGURATION-269.
--

Resolution: Fixed

Thank you for the test Oliver, I integrated it. I added a ConfigurationAssert 
class to check if two configurations are similar, that may be useful elsewhere.

 PropertiesConfiguration.save() generates superfluous escaping character when 
 delimiter parsing is disabled
 --

 Key: CONFIGURATION-269
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-269
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.4
Reporter: Oliver Heger
 Assigned To: Emmanuel Bourg
 Fix For: 1.5

 Attachments: Config-269_test.diff, properties.patch


 PropertiesConfiguration.save() ignores the delimiter parsing disabled flag 
 and escapes all delimiter characters it encounters. When the configuration is 
 loaded again (with delimiter parsing disabled) the values of affected 
 properties contain the escaping character.
 This bug is very similar to CONFIGURATION-268, but for 
 PropertiesConfiguration.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (CONFIGURATION-164) Charset detection


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Bourg updated CONFIGURATION-164:
-

Fix Version/s: (was: 1.5)
   1.6
  Environment: (was: Operating System: All
Platform: All)

 Charset detection
 -

 Key: CONFIGURATION-164
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-164
 Project: Commons Configuration
  Issue Type: Improvement
Affects Versions: Nightly Builds
Reporter: Emmanuel Bourg
Priority: Minor
 Fix For: 1.6


 Detecting automatically the charset of the file based configurations would be 
 a
 nice addition. When the file has no byte order mark defining the charset, we
 might apply a detection algorithm similar to the one implemented in Mozilla.
 There is at least one Java library providing this feature, jchardet :
 http://sourceforge.net/projects/jchardet

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (CONFIGURATION-175) Support Byte Order Marks


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emmanuel Bourg updated CONFIGURATION-175:
-

Fix Version/s: (was: 1.5)
   1.6
  Environment: (was: Operating System: All
Platform: All)

 Support Byte Order Marks
 

 Key: CONFIGURATION-175
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-175
 Project: Commons Configuration
  Issue Type: Improvement
Affects Versions: Nightly Builds
Reporter: Emmanuel Bourg
Priority: Minor
 Fix For: 1.6


 We should support byte order marks to detect automatically unicode files and
 parse them with the appropriate encoding. Here is a description of BOMs:
 http://en.wikipedia.org/wiki/Byte_Order_Mark
 I suggest the following changes:
 - add a setUseByteOrderMark() method in FileConfiguration to specify if the 
 BOM
 should be added when the file is saved
 - the useByteOrderMark flag is ignored if the encoding has no corresponding 
 BOM
 - on loading the file, look for a BOM at the beginning of the file and set the
 useByteOrderMark flag to true and switch to the corresponding encoding. The 
 flag
 is set to false by default

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (LOGGING-113) pom.xml in maven repository does not list dependencies as optional

2007-05-24 Thread Max Berger (JIRA)

pom.xml in maven repository does not list dependencies as optional
--

 Key: LOGGING-113
 URL: https://issues.apache.org/jira/browse/LOGGING-113
 Project: Commons Logging
  Issue Type: Improvement
Affects Versions: 1.1.0
 Environment: maven 2
Reporter: Max Berger
Priority: Minor


Dear Commons Logging Developers,

I don't  know if this is the right place, but I have a problem with the maven 2 
artifact for commons-logging, available at:

ftp://ibiblio.org/pub/packages/maven2/commons-logging/commons-logging/1.1/
ftp://ibiblio.org/pub/packages/maven2/commons-logging/commons-logging/1.1/commons-logging-1.1.pom

The pom lists avalon-framework, servlet-api, junit, log4j, logkit as REQUIRED 
dependencies, while instead they should be optional dependencies.

How to fix:
add  optionaltrue/optional to all dependencies that are optional, e.g. 
dependency
groupIdlog4j/groupId
artifactIdlog4j/artifactId
version1.2.12/version
optionaltrue/optional
/dependency

Thanks

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (COLLECTIONS-110) Support parametized classes with commons.collections.

[
https://issues.apache.org/jira/browse/COLLECTIONS-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Hendrik Maryns updated COLLECTIONS-110:
---

Attachment: Jakarta Collections-generic.tar.gz

Since this does not seem to evolve a bit.

I am losing my patience here, so just submitting what I have done thus far, for
my local use. Almost all classes are generified satisfactorily, except the
TreeBidiMap class. It was too complex.

Everything compiles fine on my Eclipse with java 1.6, but using ant gives some
problems, which I haven't been able to sort out.

Feel free to change whatever else you want.

I also added other stuff that is new since 1.5, such as @Override annotations.

Support parametized classes with commons.collections.
-

Key: COLLECTIONS-110
URL: https://issues.apache.org/jira/browse/COLLECTIONS-110
Project: Commons Collections
Issue Type: Wish
Environment: Operating System: other
Platform: Other
Reporter: Colbert Philippe
Fix For: Generics

Attachments: Jakarta Collections-generic.tar.gz

It's time to create a parallel version of commons.collections to support
parametized classes of each container class and abstract class. It's not
that
hard. There is a 23 PDF document on Sun Java website describing in detail
how
it should be done and what to watch out for.
I already converted a few classes from commons.collection privately for my
own
needs. Once you get the hang of it, it's a rather quick process.
I am even willing to volunteer my time to do some more but I need the
collaboration of some of the original programmers to watch over things.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[EMAIL PROTECTED]: Project commons-betwixt (in module jakarta-commons) failed

2007-05-24 Thread James Strachan

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project commons-betwixt has an issue affecting its community integration.
This issue affects 8 projects,
 and has been outstanding for 7 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-betwixt :  Commons Betwixt Package
- commons-jelly-tags-betwixt :  Commons Jelly
- commons-jelly-tags-ojb :  Commons Jelly
- db-ddlutils :  Easy-to-use component for working with Database Definition 
(...
- db-ojb-from-packages-1-0-release :  ObjectRelationalBridge
- jakarta-slide :  Content Management System based on WebDAV technology
- maven-bootstrap :  Project Management Tools
- test-ojb-from-packages-1-0-release :  ObjectRelationalBridge


Full details are available at:

http://vmgump.apache.org/gump/public/jakarta-commons/commons-betwixt/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [commons-betwixt-24052007.jar] identifier set to project 
name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/jakarta-commons/commons-betwixt/gump_work/build_jakarta-commons_commons-betwixt.html
Work Name: build_jakarta-commons_commons-betwixt (Type: Build)
Work ended in a state of : Failed
Elapsed: 3 mins 41 secs
Command Line: /opt/jdk1.5/bin/java -Djava.awt.headless=true 
-Dant.build.clonevm=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dfinal.name=commons-betwixt-24052007 
-Dresourcedir=/usr/local/gump/public/workspace/jakarta-commons/betwixt jar 
[Working Directory: /usr/local/gump/public/workspace/jakarta-commons/betwixt]
CLASSPATH: 
/opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/betwixt/target/classes:/usr/local/gump/public/workspace/jakarta-commons/betwixt/target/test-classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/packages/junit3.8.1/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/usr/local/gump/public/workspace/jakarta-commons/digester/dist/commons-digester.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-24052007.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-24052007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-24052007.jar:/usr/local/gump/public/workspace/junit/dist/junit-24052007.jar
-
[junit] May 24, 2007 4:45:40 AM 
org.apache.commons.betwixt.versioning.VersioningStrategy checkVersionUntil
[junit] INFO: value=null
[junit] May 24, 2007 4:45:40 AM 
org.apache.commons.betwixt.versioning.VersioningStrategy checkVersionUntil
[junit] INFO: version=3
[junit] May 24, 2007 4:45:40 AM 
org.apache.commons.betwixt.versioning.VersioningStrategy debugOptions
[junit] INFO: Names:
[junit] May 24, 2007 4:45:40 AM 
org.apache.commons.betwixt.versioning.VersioningStrategy debugOptions
[junit] INFO:   0: version-from=2
[junit] May 24, 2007 4:45:40 AM 
org.apache.commons.betwixt.versioning.VersioningStrategy checkVersionUntil
[junit] INFO: No attribute Version until
[junit] May 24, 2007 4:45:40 AM 
org.apache.commons.betwixt.versioning.VersioningStrategy suppress
[junit] INFO: Showing element
[junit] May 24, 2007 4:45:40 AM 
org.apache.commons.betwixt.versioning.TestVersioning testWrite4
[junit] INFO: Written:
[junit] VersioningTestData attribute1=attributevalue1
[junit] element1elementvalue1/element1
[junit] element2elementvalue2/element2
[junit] /VersioningTestData
[junit] 
[junit] May 24, 2007 4:45:40 AM 
org.apache.commons.betwixt.versioning.TestVersioning testWrite4
[junit] INFO:

[EMAIL PROTECTED]: Project commons-betwixt (in module jakarta-commons) failed

2007-05-24 Thread James Strachan

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project commons-betwixt has an issue affecting its community integration.
This issue affects 8 projects,
 and has been outstanding for 7 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-betwixt :  Commons Betwixt Package
- commons-jelly-tags-betwixt :  Commons Jelly
- commons-jelly-tags-ojb :  Commons Jelly
- db-ddlutils :  Easy-to-use component for working with Database Definition 
(...
- db-ojb-from-packages-1-0-release :  ObjectRelationalBridge
- jakarta-slide :  Content Management System based on WebDAV technology
- maven-bootstrap :  Project Management Tools
- test-ojb-from-packages-1-0-release :  ObjectRelationalBridge


Full details are available at:

http://vmgump.apache.org/gump/public/jakarta-commons/commons-betwixt/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [commons-betwixt-24052007.jar] identifier set to project 
name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/jakarta-commons/commons-betwixt/gump_work/build_jakarta-commons_commons-betwixt.html
Work Name: build_jakarta-commons_commons-betwixt (Type: Build)
Work ended in a state of : Failed
Elapsed: 3 mins 41 secs
Command Line: /opt/jdk1.5/bin/java -Djava.awt.headless=true 
-Dant.build.clonevm=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dfinal.name=commons-betwixt-24052007 
-Dresourcedir=/usr/local/gump/public/workspace/jakarta-commons/betwixt jar 
[Working Directory: /usr/local/gump/public/workspace/jakarta-commons/betwixt]
CLASSPATH: 
/opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/betwixt/target/classes:/usr/local/gump/public/workspace/jakarta-commons/betwixt/target/test-classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/packages/junit3.8.1/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/usr/local/gump/public/workspace/jakarta-commons/digester/dist/commons-digester.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-24052007.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-24052007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-24052007.jar:/usr/local/gump/public/workspace/junit/dist/junit-24052007.jar
-
[junit] May 24, 2007 4:45:40 AM 
org.apache.commons.betwixt.versioning.VersioningStrategy checkVersionUntil
[junit] INFO: value=null
[junit] May 24, 2007 4:45:40 AM 
org.apache.commons.betwixt.versioning.VersioningStrategy checkVersionUntil
[junit] INFO: version=3
[junit] May 24, 2007 4:45:40 AM 
org.apache.commons.betwixt.versioning.VersioningStrategy debugOptions
[junit] INFO: Names:
[junit] May 24, 2007 4:45:40 AM 
org.apache.commons.betwixt.versioning.VersioningStrategy debugOptions
[junit] INFO:   0: version-from=2
[junit] May 24, 2007 4:45:40 AM 
org.apache.commons.betwixt.versioning.VersioningStrategy checkVersionUntil
[junit] INFO: No attribute Version until
[junit] May 24, 2007 4:45:40 AM 
org.apache.commons.betwixt.versioning.VersioningStrategy suppress
[junit] INFO: Showing element
[junit] May 24, 2007 4:45:40 AM 
org.apache.commons.betwixt.versioning.TestVersioning testWrite4
[junit] INFO: Written:
[junit] VersioningTestData attribute1=attributevalue1
[junit] element1elementvalue1/element1
[junit] element2elementvalue2/element2
[junit] /VersioningTestData
[junit] 
[junit] May 24, 2007 4:45:40 AM 
org.apache.commons.betwixt.versioning.TestVersioning testWrite4
[junit] INFO:

[jira] Updated: (COLLECTIONS-110) Support parametized classes with commons.collections.


 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hendrik Maryns updated COLLECTIONS-110:
---

Attachment: collections.patch

The same as a patch.

 Support parametized classes with commons.collections.
 -

 Key: COLLECTIONS-110
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-110
 Project: Commons Collections
  Issue Type: Wish
 Environment: Operating System: other
 Platform: Other
Reporter: Colbert Philippe
 Fix For: Generics

 Attachments: collections.patch, Jakarta Collections-generic.tar.gz


 It's time to create a parallel version of commons.collections to support 
 parametized classes of each container class and abstract class.  It's not 
 that 
 hard.  There is a 23 PDF document on Sun Java website describing in detail 
 how 
 it should be done and what to watch out for.
 I already converted a few classes from commons.collection privately for my 
 own 
 needs.  Once you get the hang of it, it's a rather quick process.
 I am even willing to volunteer my time to do some more but I need the 
 collaboration of some of the original programmers to watch over things.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (LANG-336) Finally start using generics.

2007-05-24 Thread Tom Nichols (JIRA)


[ 
https://issues.apache.org/jira/browse/LANG-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498626
 ] 

Tom Nichols commented on LANG-336:
--

I agree, generics would be nice.  

I'm not familiar with Jakarta's development policies, but would it be 
appropriate to create and maintain a branch with generics support, and have two 
distributions (java 5+ and pre-Java 5)?

 Finally start using generics.
 -

 Key: LANG-336
 URL: https://issues.apache.org/jira/browse/LANG-336
 Project: Commons Lang
  Issue Type: Improvement
Affects Versions: 2.3
Reporter: Hendrik Maryns
 Attachments: commons-lang-2.3-sources-generic.tar.gz, lang.patch


 It is obvious that the Jakarta  project is reluctant in starting to use the 
 'new' (how old is it by now?) generics feature of Java.  Nevertheless some 
 other people would like to see it incorporated in the commons projects.
 I adapted commons Lang to usee generics.  Took me about an afternoon.  Would 
 be nice if something is done with it, except for only me using it in my 
 projects.
 Some stuff will have to be changed to conform to guidelines and stuff.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (LANG-336) Finally start using generics.

2007-05-24 Thread Antonio Petrelli (JIRA)


[ 
https://issues.apache.org/jira/browse/LANG-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498628
 ] 

Antonio Petrelli commented on LANG-336:
---

About backward compatibility, consider using Retrotranslator.

 Finally start using generics.
 -

 Key: LANG-336
 URL: https://issues.apache.org/jira/browse/LANG-336
 Project: Commons Lang
  Issue Type: Improvement
Affects Versions: 2.3
Reporter: Hendrik Maryns
 Attachments: commons-lang-2.3-sources-generic.tar.gz, lang.patch


 It is obvious that the Jakarta  project is reluctant in starting to use the 
 'new' (how old is it by now?) generics feature of Java.  Nevertheless some 
 other people would like to see it incorporated in the commons projects.
 I adapted commons Lang to usee generics.  Took me about an afternoon.  Would 
 be nice if something is done with it, except for only me using it in my 
 projects.
 Some stuff will have to be changed to conform to guidelines and stuff.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (JXPATH-86) Children returned instead of self for arrays when using . selector

2007-05-24 Thread Adam Crume (JIRA)


[ 
https://issues.apache.org/jira/browse/JXPATH-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498636
 ] 

Adam Crume commented on JXPATH-86:
--

I understand that getValue() and getPointer() return only the first matching 
value.  However, /array/* is still returning the wrong value because it 
should be equivalent to /[EMAIL PROTECTED]'array'][1] , not /[EMAIL 
PROTECTED]'array'][1]/bytes[1].  In other words, it should return one 
instead of 111.

 Children returned instead of self for arrays when using . selector
 --

 Key: JXPATH-86
 URL: https://issues.apache.org/jira/browse/JXPATH-86
 Project: Commons JXPath
  Issue Type: Bug
Affects Versions: 1.2 Final
Reporter: Adam Crume

 The . selector should always return the context node, and the * selector 
 should return child elements.  However, this doesn't work for arrays:
 JXPathContext context = JXPathContext.newContext(new HashMap());
 context.setValue(array, new String[] {one, two, three});
 context.setValue(array2, new String[][] { {a, b}, {c, d}});
 context.setValue(person, new Person(Bob, 25));
 String[] paths = {/array, /array/., /array/*, /person, /person/., 
 /person/*};
 for(int i = 0; i  paths.length; i++) {
   Pointer pointer = context.getPointer(paths[i]);
   System.out.println(pointer.asPath());
   Object value = context.getValue(paths[i]);
   System.out.println(value);
   System.out.println();
 }
 This produces the following output:
 /[EMAIL PROTECTED]'array']
 [Ljava.lang.String;@59b659b6
 /[EMAIL PROTECTED]'array'][1]
 one
 /[EMAIL PROTECTED]'array'][1]/bytes[1]
 111
 /[EMAIL PROTECTED]'person']
 [EMAIL PROTECTED]
 /[EMAIL PROTECTED]'person']
 [EMAIL PROTECTED]
 /[EMAIL PROTECTED]'person']/age
 25

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (BEANUTILS-87) Package scope implementation of public interface for mapped property fails


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton updated BEANUTILS-87:
-

 Assignee: Niall Pemberton
Affects Version/s: 1.7.0
  Summary: Package scope implementation of public interface for 
mapped property fails  (was: [beanutils] Can't access mapped property in some 
case)

 Package scope implementation of public interface for mapped property fails
 --

 Key: BEANUTILS-87
 URL: https://issues.apache.org/jira/browse/BEANUTILS-87
 Project: Commons BeanUtils
  Issue Type: Bug
  Components: Bean / Property Utils
Affects Versions: 1.7.0
 Environment: Operating System: All
 Platform: PC
Reporter: YOKOTA Takehiko
 Assigned To: Niall Pemberton
 Fix For: 1.8.0

 Attachments: mapped.patch, mappedTest.patch, test.tar.gz, test2.tar.gz


 In the following case, access to mapped property fails by 
 IllegalAccessException.
 Assume that 'bean' is an instance of package scoped class
 which implements public interface 'I', and interface 'I' has 
 a method 'getValue(String key)'.
 In the case PropertyUtils.getProperty(bean, value(key)) is called,
 IllegalAccessException occures.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r541308 - in /jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/bugs: ./ Jira87TestCase.java other/ other/Jira87BeanFactory.java

Author: niallp
Date: Thu May 24 07:31:50 2007
New Revision: 541308

URL: http://svn.apache.org/viewvc?view=revrev=541308
Log:
BEANUTILS-87 - Package scope implementation of a public interface for mapped 
property fails. Adding a test case to prove that this has been resolved 
(running the test with BeanUtils 1.7.0 failed, but passes with current 
BeanUtils trunk) - fixed by changes to MappedPropertyDescriptor associated with 
BEANUTILS-6)

Added:

jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/bugs/

jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/bugs/Jira87TestCase.java
   (with props)

jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/bugs/other/

jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/bugs/other/Jira87BeanFactory.java
   (with props)

Added: 
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/bugs/Jira87TestCase.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/bugs/Jira87TestCase.java?view=autorev=541308
==
--- 
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/bugs/Jira87TestCase.java
 (added)
+++ 
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/bugs/Jira87TestCase.java
 Thu May 24 07:31:50 2007
@@ -0,0 +1,104 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the License); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.beanutils.bugs;
+
+import org.apache.commons.beanutils.PropertyUtils;
+import org.apache.commons.beanutils.bugs.other.Jira87BeanFactory;
+import org.apache.commons.logging.Log;
+import org.apache.commons.logging.LogFactory;
+import junit.framework.Test;
+import junit.framework.TestCase;
+import junit.framework.TestSuite;
+
+/**
+ * Test case for Jiar issue# BEANUTILS-87.
+ * p /
+ * See https://issues.apache.org/jira/browse/BEANUTILS-87
+ * p /
+ * In BeanUtils 1.7.0 a package friendly implementation
+ * of a public interface with defined a mapped property
+ * caused an [EMAIL PROTECTED] IllegalAccessException} to be thrown by
+ * PropertyUtils's getMappedProperty method.
+ * p /
+ * This test case demonstrates the issue.
+ *
+ * @version $Revision$ $Date$
+ */
+public class Jira87TestCase extends TestCase {
+
+private Log log = LogFactory.getLog(Jira87TestCase.class);
+
+/**
+ * Create a test case with the specified name.
+ *
+ * @param name The name of the test
+ */
+public Jira87TestCase(String name) {
+super(name);
+}
+
+/**
+ * Run the Test.
+ *
+ * @param args Arguments
+ */
+public static void main(String[] args) {
+junit.textui.TestRunner.run(suite());
+}
+
+/**
+ * Create a test suite for this test.
+ *
+ * @return a test suite
+ */
+public static Test suite() {
+return (new TestSuite(Jira87TestCase.class));
+}
+
+/**
+ * Set up.
+ *
+ * @throws java.lang.Exception
+ */
+protected void setUp() throws Exception {
+super.setUp();
+}
+
+/**
+ * Tear Down.
+ *
+ * @throws java.lang.Exception
+ */
+protected void tearDown() throws Exception {
+super.tearDown();
+}
+
+/**
+ * Interface definition with a mapped property
+ */
+public void testJira87() {
+
+Jira87BeanFactory.PublicMappedInterface bean = 
Jira87BeanFactory.createMappedPropertyBean();
+try {
+// N.B. The test impl. returns the key value
+assertEquals(foo, PropertyUtils.getMappedProperty(bean, 
value(foo)));
+} catch (Throwable t) {
+log.error(ERROR  + t, t);
+fail(Threw exception:  + t);
+}
+}
+}

Propchange: 
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/bugs/Jira87TestCase.java
--
svn:eol-style = native

Propchange: 
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/bugs/Jira87TestCase.java

[jira] Resolved: (BEANUTILS-87) Package scope implementation of public interface for mapped property fails


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton resolved BEANUTILS-87.
--

Resolution: Fixed

I added a test case for this issue - which I have verified fails for BeanUtils 
1.7.0, but passes for the current trunk. Changes to MappedPropertyDescriptor 
associated with BEANUTILS-6 have resolved this issue.

 Package scope implementation of public interface for mapped property fails
 --

 Key: BEANUTILS-87
 URL: https://issues.apache.org/jira/browse/BEANUTILS-87
 Project: Commons BeanUtils
  Issue Type: Bug
  Components: Bean / Property Utils
Affects Versions: 1.7.0
 Environment: Operating System: All
 Platform: PC
Reporter: YOKOTA Takehiko
 Assigned To: Niall Pemberton
 Fix For: 1.8.0

 Attachments: mapped.patch, mappedTest.patch, test.tar.gz, test2.tar.gz


 In the following case, access to mapped property fails by 
 IllegalAccessException.
 Assume that 'bean' is an instance of package scoped class
 which implements public interface 'I', and interface 'I' has 
 a method 'getValue(String key)'.
 In the case PropertyUtils.getProperty(bean, value(key)) is called,
 IllegalAccessException occures.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (JXPATH-86) Children returned instead of self for arrays when using . selector

2007-05-24 Thread Matt Benson (JIRA)


[ 
https://issues.apache.org/jira/browse/JXPATH-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498664
 ] 

Matt Benson commented on JXPATH-86:
---

ah, point taken on that last example.  I am researching as time permits.

 Children returned instead of self for arrays when using . selector
 --

 Key: JXPATH-86
 URL: https://issues.apache.org/jira/browse/JXPATH-86
 Project: Commons JXPath
  Issue Type: Bug
Affects Versions: 1.2 Final
Reporter: Adam Crume

 The . selector should always return the context node, and the * selector 
 should return child elements.  However, this doesn't work for arrays:
 JXPathContext context = JXPathContext.newContext(new HashMap());
 context.setValue(array, new String[] {one, two, three});
 context.setValue(array2, new String[][] { {a, b}, {c, d}});
 context.setValue(person, new Person(Bob, 25));
 String[] paths = {/array, /array/., /array/*, /person, /person/., 
 /person/*};
 for(int i = 0; i  paths.length; i++) {
   Pointer pointer = context.getPointer(paths[i]);
   System.out.println(pointer.asPath());
   Object value = context.getValue(paths[i]);
   System.out.println(value);
   System.out.println();
 }
 This produces the following output:
 /[EMAIL PROTECTED]'array']
 [Ljava.lang.String;@59b659b6
 /[EMAIL PROTECTED]'array'][1]
 one
 /[EMAIL PROTECTED]'array'][1]/bytes[1]
 111
 /[EMAIL PROTECTED]'person']
 [EMAIL PROTECTED]
 /[EMAIL PROTECTED]'person']
 [EMAIL PROTECTED]
 /[EMAIL PROTECTED]'person']/age
 25

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Closed: (DBCP-224) Null delegate possible


 [ 
https://issues.apache.org/jira/browse/DBCP-224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Henri Yandell closed DBCP-224.
--

Resolution: Duplicate

Thanks for the report Anatoliy.

I'm closing this in favour of the slightly newer DBCP-225 as they appear to be 
the same issue and that issue has more information.

 Null delegate possible
 --

 Key: DBCP-224
 URL: https://issues.apache.org/jira/browse/DBCP-224
 Project: Commons Dbcp
  Issue Type: Bug
Affects Versions: 1.2.2
Reporter: Anatoliy Salistra

 java.lang.NullPointerException
at 
 org.apache.commons.dbcp.DelegatingConnection.setAutoCommit(DelegatingConnection.java:268)
at 
 org.apache.commons.dbcp.PoolableConnectionFactory.activateObject(PoolableConnectionFactory.java:368)
at 
 org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:786)
at 
 org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:95)
at 
 org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:540)
at 
 com.gfigroup.fmk.spine.db.NamedDBCPDataSource.getConnection(NamedDBCPDataSource.java:123)
at 
 com.gfigroup.fmk.spine.tx.TransactionContext.createConnection(TransactionContext.java:99)
at 
 com.gfigroup.fmk.spine.tx.TransactionContext.getConnection(TransactionContext.java:75)
at 
 com.gfigroup.fmk.spine.tx.TransactionContext.getConnectionFacility(TransactionContext.java:91)
at 
 com.gfigroup.fmk.spine.tx.AbstractTxObject.getConnectionFacility(AbstractTxObject.java:47)
at 
 com.gfigroup.ts.credit.service.feed.btc.BTCTradeTxObjectImpl.insertTrade(BTCTradeTxObjectImpl.java:104)
at sun.reflect.GeneratedMethodAccessor49.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at 
 com.gfigroup.fmk.spine.tx.TxObjectService$TxObjectStub.invoke(TxObjectService.java:319)
at $Proxy15.insertTrade(Unknown Source)
at 
 com.gfigroup.ts.credit.service.feed.btc.BTCListenerService.handleTrade(BTCListenerService.java:323)
at 
 com.gfigroup.ts.credit.service.feed.btc.BTCListenerService.handleTradeMessage(BTCListenerService.java:308)
at 
 com.gfigroup.ts.credit.service.feed.btc.BTCListenerService.access$800(BTCListenerService.java:37)
at 
 com.gfigroup.ts.credit.service.feed.btc.BTCListenerService$ProcessTradeMessageTask.run(BTCListenerService.java:512)
at 
 edu.oswego.cs.dl.util.concurrent.QueuedExecutor$RunLoop.run(QueuedExecutor.java:88)
at java.lang.Thread.run(Unknown Source)
 This happens intermittently and very mysteriously. Eventually our pool 
 becomes clogged with undead connections like this. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r541327 - in /jakarta/commons/proper/beanutils/trunk/src: java/org/apache/commons/beanutils/PropertyUtilsBean.java test/org/apache/commons/beanutils/PropertyUtilsTestCase.java

Author: niallp
Date: Thu May 24 08:38:56 2007
New Revision: 541327

URL: http://svn.apache.org/viewvc?view=revrev=541327
Log:
BEANUTILS-88 PropertyUtilsBean.isReadable/isWriteable always returns false for 
mapped properties - thanks to Chuck Daniels

Modified:

jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/PropertyUtilsBean.java

jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/PropertyUtilsTestCase.java

Modified: 
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/PropertyUtilsBean.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/PropertyUtilsBean.java?view=diffrev=541327r1=541326r2=541327
==
--- 
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/PropertyUtilsBean.java
 (original)
+++ 
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/PropertyUtilsBean.java
 Thu May 24 08:38:56 2007
@@ -1328,9 +1328,12 @@
 getPropertyDescriptor(bean, name);
 if (desc != null) {
 Method readMethod = desc.getReadMethod();
-if ((readMethod == null) 
-(desc instanceof IndexedPropertyDescriptor)) {
-readMethod = ((IndexedPropertyDescriptor) 
desc).getIndexedReadMethod();
+if (readMethod == null) {
+if (desc instanceof IndexedPropertyDescriptor) {
+readMethod = ((IndexedPropertyDescriptor) 
desc).getIndexedReadMethod();
+} else if (desc instanceof MappedPropertyDescriptor) {
+readMethod = ((MappedPropertyDescriptor) 
desc).getMappedReadMethod();
+}
 }
 return (readMethod != null);
 } else {
@@ -1384,9 +1387,12 @@
 getPropertyDescriptor(bean, name);
 if (desc != null) {
 Method writeMethod = desc.getWriteMethod();
-if ((writeMethod == null) 
-(desc instanceof IndexedPropertyDescriptor)) {
-writeMethod = ((IndexedPropertyDescriptor) 
desc).getIndexedWriteMethod();
+if (writeMethod == null) {
+if (desc instanceof IndexedPropertyDescriptor) {
+writeMethod = ((IndexedPropertyDescriptor) 
desc).getIndexedWriteMethod();
+} else if (desc instanceof MappedPropertyDescriptor) {
+writeMethod = ((MappedPropertyDescriptor) 
desc).getMappedWriteMethod();
+}
 }
 return (writeMethod != null);
 } else {

Modified: 
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/PropertyUtilsTestCase.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/PropertyUtilsTestCase.java?view=diffrev=541327r1=541326r2=541327
==
--- 
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/PropertyUtilsTestCase.java
 (original)
+++ 
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/PropertyUtilsTestCase.java
 Thu May 24 08:38:56 2007
@@ -2076,6 +2076,60 @@
 
 }
 
+/**
+ * Test isReadable() method.
+ */
+public void testIsReadable() {
+TestBean bean = new TestBean();
+String property = null;
+try {
+property = stringProperty;
+assertTrue(Property  + property + isReadable expeced TRUE, 
PropertyUtils.isReadable(bean, property));
+} catch (Throwable t) {
+fail(Property  + property + isReadable Threw exception:  + t);
+}
+try {
+property = stringIndexed;
+assertTrue(Property  + property + isReadable expeced TRUE, 
PropertyUtils.isReadable(bean, property));
+} catch (Throwable t) {
+fail(Property  + property + isReadable Threw exception:  + t);
+}
+try {
+property = mappedProperty;
+assertTrue(Property  + property + isReadable expeced TRUE, 
PropertyUtils.isReadable(bean, property));
+} catch (Throwable t) {
+fail(Property  + property + isReadable Threw exception:  + t);
+}
+
+}
+
+/**
+ * Test isReadable() method.
+ */
+public void testIsWriteable() {
+TestBean bean = new TestBean();
+String property = null;
+try {
+property = stringProperty;
+assertTrue(Property  + property + isWriteable expeced TRUE, 
PropertyUtils.isWriteable(bean, property));

[jira] Updated: (BEANUTILS-88) PropertyUtilsBean.isReadable/isWriteable always returns false for mapped properties


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton updated BEANUTILS-88:
-

 Assignee: Niall Pemberton
Affects Version/s: 1.7.0
  Summary: PropertyUtilsBean.isReadable/isWriteable always returns 
false for mapped properties  (was: [beanutils] 
PropertyUtilsBean.isReadable/isWriteable always returns false for mapped 
properties)

 PropertyUtilsBean.isReadable/isWriteable always returns false for mapped 
 properties
 ---

 Key: BEANUTILS-88
 URL: https://issues.apache.org/jira/browse/BEANUTILS-88
 Project: Commons BeanUtils
  Issue Type: Bug
  Components: Bean / Property Utils
Affects Versions: 1.7.0
 Environment: Operating System: All
 Platform: All
Reporter: Chuck Daniels
 Assigned To: Niall Pemberton
 Fix For: 1.8.0


 PropertyUtilsBean.isReadable/isWriteable always returns false for mapped 
 properties because it does not account for them.  The core logic within the 
 try 
 block of the isReadable method should look as follows (the logic for 
 isWriteable should be updated similarly):
 PropertyDescriptor desc =
 getPropertyDescriptor(bean, name);
 if (desc != null) {
 Method readMethod = desc.getReadMethod();
 if (readMethod == null) {
 if (desc instanceof IndexedPropertyDescriptor) {
 readMethod = ((IndexedPropertyDescriptor) 
 desc).getIndexedReadMethod
 ();
 } else if (desc instanceof MappedPropertyDescriptor) {
 readMethod = ((MappedPropertyDescriptor) desc).getMappedReadMethod
 ();
 }
 }
 return (readMethod != null);
 } else {
 return (false);
 }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r541336 - /jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/PropertyUtilsTestCase.java

Author: niallp
Date: Thu May 24 08:46:10 2007
New Revision: 541336

URL: http://svn.apache.org/viewvc?view=revrev=541336
Log:
Minor javadoc correction

Modified:

jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/PropertyUtilsTestCase.java

Modified: 
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/PropertyUtilsTestCase.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/PropertyUtilsTestCase.java?view=diffrev=541336r1=541335r2=541336
==
--- 
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/PropertyUtilsTestCase.java
 (original)
+++ 
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/PropertyUtilsTestCase.java
 Thu May 24 08:46:10 2007
@@ -2104,7 +2104,7 @@
 }
 
 /**
- * Test isReadable() method.
+ * Test isWriteable() method.
  */
 public void testIsWriteable() {
 TestBean bean = new TestBean();



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[EMAIL PROTECTED]: Project commons-jelly-tags-jsl-test (in module commons-jelly) failed

2007-05-24 Thread commons-jelly-tags-jsl development

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project commons-jelly-tags-jsl-test has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 9 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-jsl-test :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Dependency on ant exists, no need to add for property 
maven.jar.ant-optional.
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -WARNING- Overriding Maven properties: 
[/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties]
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.properties
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/test-reports



The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/gump_work/build_commons-jelly_commons-jelly-tags-jsl-test.html
Work Name: build_commons-jelly_commons-jelly-tags-jsl-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 15 secs
Command Line: maven --offline jar 
[Working Directory: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl]
CLASSPATH: 
/opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/commons-cli-1.0.x/target/commons-cli-24052007.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-24052007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-24052007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-24052007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-24052007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-24052007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-24052007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-24052007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-24052007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-24052007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-24052007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar
-
[junit] at 
org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:64)
[junit] at 
org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:59)
[junit] at 
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:263)
[junit] at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96)
[junit] at 
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187)
[junit] at 
org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:66)
[junit] at 
org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:113)
[junit] at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96)
[junit] at 
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187)
[junit] at 
org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:161)
[junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59)
[junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:80)
[junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:171)
[junit] at

[EMAIL PROTECTED]: Project commons-jelly-tags-jsl-test (in module commons-jelly) failed

2007-05-24 Thread commons-jelly-tags-jsl development

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project commons-jelly-tags-jsl-test has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 9 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-jsl-test :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Dependency on ant exists, no need to add for property 
maven.jar.ant-optional.
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -WARNING- Overriding Maven properties: 
[/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties]
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.properties
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/test-reports



The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/gump_work/build_commons-jelly_commons-jelly-tags-jsl-test.html
Work Name: build_commons-jelly_commons-jelly-tags-jsl-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 15 secs
Command Line: maven --offline jar 
[Working Directory: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl]
CLASSPATH: 
/opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/commons-cli-1.0.x/target/commons-cli-24052007.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-24052007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-24052007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-24052007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-24052007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-24052007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-24052007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-24052007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-24052007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-24052007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-24052007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar
-
[junit] at 
org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:64)
[junit] at 
org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:59)
[junit] at 
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:263)
[junit] at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96)
[junit] at 
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187)
[junit] at 
org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:66)
[junit] at 
org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:113)
[junit] at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96)
[junit] at 
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187)
[junit] at 
org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:161)
[junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59)
[junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:80)
[junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:171)
[junit] at

[jira] Updated: (BEANUTILS-33) Can't use dot in mapped properties for setProperty or getPropertyDescriptor


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton updated BEANUTILS-33:
-

Affects Version/s: 1.7.0
  Summary: Can't use dot in mapped properties for setProperty or 
getPropertyDescriptor  (was: [beanutils] Can't use . (dot) in mapped properties 
for setProperty or getPropertyDescriptor)

 Can't use dot in mapped properties for setProperty or getPropertyDescriptor
 -

 Key: BEANUTILS-33
 URL: https://issues.apache.org/jira/browse/BEANUTILS-33
 Project: Commons BeanUtils
  Issue Type: Bug
  Components: Expression Syntax
Affects Versions: 1.7.0
 Environment: Operating System: other
 Platform: Other
Reporter: Eoin Curran
 Fix For: 1.8.0

 Attachments: beanutils.dotsinmappedindices.patch, 
 PropertyUtilsMappedDot.txt, PropertyUtilsMappedIssues.txt, 
 PropertyUtilsTestCase1.txt, PropertyUtilsTestMappedDot.txt


 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10478
 fixed this problem for PropertyUtils.getProperty(); However, the problem 
 remains
 for setProperty and getPropertyDescriptor.
 I have fixed this against 1.6.1

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[EMAIL PROTECTED]: Project commons-jelly-tags-fmt-test (in module commons-jelly) failed

2007-05-24 Thread commons-jelly-tags-fmt development

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project commons-jelly-tags-fmt-test has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 9 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-fmt-test :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -WARNING- Overriding Maven properties: 
[/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties]
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.properties
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/test-reports



The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/gump_work/build_commons-jelly_commons-jelly-tags-fmt-test.html
Work Name: build_commons-jelly_commons-jelly-tags-fmt-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 11 secs
Command Line: maven --offline jar 
[Working Directory: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt]
CLASSPATH: 
/opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-commands-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-classpath-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-core-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-bsf-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-reflect-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-util-2.0b4.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-24052007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-24052007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-24052007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/beanshell/target/commons-jelly-tags-beanshell-24052007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-24052007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-24052007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-24052007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-24052007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-24052007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/commons-jelly-tags-fmt-24052007.jar
-
[junit] at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
[junit] at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
[junit] at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
[junit] at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
[junit] at java.security.AccessController.doPrivileged(Native Method)
[junit] at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
[junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
[junit] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
[junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
[junit] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
[junit] at 
org.apache.commons.jelly.tags.ant.AntTagLibrary.createProject(AntTagLibrary.java:128)

[EMAIL PROTECTED]: Project commons-jelly-tags-fmt-test (in module commons-jelly) failed

2007-05-24 Thread commons-jelly-tags-fmt development

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project commons-jelly-tags-fmt-test has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 9 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-fmt-test :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -WARNING- Overriding Maven properties: 
[/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties]
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.properties
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/test-reports



The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/gump_work/build_commons-jelly_commons-jelly-tags-fmt-test.html
Work Name: build_commons-jelly_commons-jelly-tags-fmt-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 11 secs
Command Line: maven --offline jar 
[Working Directory: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt]
CLASSPATH: 
/opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-commands-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-classpath-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-core-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-bsf-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-reflect-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-util-2.0b4.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-24052007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-24052007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-24052007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/beanshell/target/commons-jelly-tags-beanshell-24052007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-24052007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-24052007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-24052007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-24052007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-24052007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/commons-jelly-tags-fmt-24052007.jar
-
[junit] at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
[junit] at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
[junit] at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
[junit] at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
[junit] at java.security.AccessController.doPrivileged(Native Method)
[junit] at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
[junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
[junit] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
[junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
[junit] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
[junit] at 
org.apache.commons.jelly.tags.ant.AntTagLibrary.createProject(AntTagLibrary.java:128)

[jira] Commented: (DBCP-225) getConnection / borrowObject fails with NullPointerException

2007-05-24 Thread Anatoliy Salistra (JIRA)


[ 
https://issues.apache.org/jira/browse/DBCP-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498695
 ] 

Anatoliy Salistra commented on DBCP-225:


The situation is even more mysterious since the DelegatingConnection in 
question is PoolableConnection, and no code ever calls setDelegate(null) on 
PoolableConnection.

 getConnection / borrowObject fails with NullPointerException
 

 Key: DBCP-225
 URL: https://issues.apache.org/jira/browse/DBCP-225
 Project: Commons Dbcp
  Issue Type: Bug
Affects Versions: 1.2.1, 1.2.2
 Environment: Solaris 10, Oracle 10g RAC
Reporter: Alexei Samonov

 We use dbcp PoolingDataSource in Solaris/Oracle 10g RAC environment and our 
 getConnection calls fail sporadically with the following stack trace (1.2.1)
 Caused by: org.apache.commons.dbcp.SQLNestedException: Cannot get a 
 connection, pool exhausted
 at 
 org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:103)
 at 
 org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:540)
 ... more
 Caused by: java.util.NoSuchElementException: Could not create a validated 
 object, cause: null
 at 
 org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:806)
 at 
 org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:95)
 ... 24 more
 This is definitely not a pool exhausted situation, it is just being 
 reported as pool exhausted. Since NoSuchElementException that you use does 
 not allow cause, only Exception message (null) is being printed. With some 
 debugging I was able to recover the root exception:
 java.lang.NullPointerException
 at 
 org.apache.commons.dbcp.DelegatingConnection.setAutoCommit(DelegatingConnection.java:268)
 at 
 org.apache.commons.dbcp.PoolableConnectionFactory.activateObject(PoolableConnectionFactory.java:368)
 at 
 org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:786)
 at 
 org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:95)
 at 
 org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:540)
 ...
 Looks like it is trying to borrow/validate DelegatingConnection which 
 delegate is null.
 Hoping to resolve the issue we upgraded to 1.2.2 but it did not help. Here is 
 is an exception stack trace from 1.2.2:
 org.apache.commons.dbcp.SQLNestedException: Cannot get a connection, pool 
 error Could not create a validated object, cause: null
 at 
 org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:104)
 at 
 org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:880)
 ... more
 Caused by: java.util.NoSuchElementException: Could not create a validated 
 object, cause: null
 at 
 org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:871)
 at 
 org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:96)
 ... 28 more
 We use the following dbcp properties:
 autoCommit=false
 readOnly=false
 maxActive=200
 maxIdle=20
 minIdle=10
 minEvictableIdleIime=30
 maxWait=200
 accessToUnderlyingConnectionAllowed=true
 validationQuery=SELECT 1 FROM DUAL
 I could not find the existing reported dbcp/object pool bug but I see similar 
  reports on the web, for example 
 http://forum.java.sun.com/thread.jspa?threadID=713200messageID=4124915

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (DBCP-225) getConnection / borrowObject fails with NullPointerException

2007-05-24 Thread Alexei Samonov (JIRA)


 [ 
https://issues.apache.org/jira/browse/DBCP-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexei Samonov updated DBCP-225:


Description: 
We use dbcp PoolingDataSource in Solaris/Oracle 10g RAC environment and our 
getConnection calls fail sporadically with the following stack trace (1.2.1)

Caused by: org.apache.commons.dbcp.SQLNestedException: Cannot get a connection, 
pool exhausted
at 
org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:103)
at 
org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:540)
... more
Caused by: java.util.NoSuchElementException: Could not create a validated 
object, cause: null
at 
org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:806)
at 
org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:95)
... 24 more

This is definitely not a pool exhausted situation, it is just being reported 
as pool exhausted. Since NoSuchElementException that you use does not allow 
cause, only Exception message (null) is being printed. With some debugging I 
was able to recover the root exception:

java.lang.NullPointerException
at 
org.apache.commons.dbcp.DelegatingConnection.setAutoCommit(DelegatingConnection.java:268)
at 
org.apache.commons.dbcp.PoolableConnectionFactory.activateObject(PoolableConnectionFactory.java:368)
at 
org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:786)
at 
org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:95)
at 
org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:540)
...

Looks like it is trying to borrow/validate DelegatingConnection which delegate 
is null.



Hoping to resolve the issue we upgraded to 1.2.2 but it did not help. Here is 
is an exception stack trace from 1.2.2:

org.apache.commons.dbcp.SQLNestedException: Cannot get a connection, pool error 
Could not create a validated object, cause: null
at 
org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:104)
at 
org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:880)
... more
Caused by: java.util.NoSuchElementException: Could not create a validated 
object, cause: null
at 
org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:871)
at 
org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:96)
... 28 more


We use the following dbcp properties:

autoCommit=false
readOnly=false
maxActive=200
maxIdle=20
minIdle=10
minEvictableIdleIime=30
maxWait=200
accessToUnderlyingConnectionAllowed=true
validationQuery=SELECT 1 FROM DUAL
ConnectionCachingEnabled=true
FastConnectionFailoverEnabled=true



I could not find the existing reported dbcp/object pool bug but I see similar  
reports on the web, for example 
http://forum.java.sun.com/thread.jspa?threadID=713200messageID=4124915

  was:
We use dbcp PoolingDataSource in Solaris/Oracle 10g RAC environment and our 
getConnection calls fail sporadically with the following stack trace (1.2.1)

Caused by: org.apache.commons.dbcp.SQLNestedException: Cannot get a connection, 
pool exhausted
at 
org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:103)
at 
org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:540)
... more
Caused by: java.util.NoSuchElementException: Could not create a validated 
object, cause: null
at 
org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:806)
at 
org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:95)
... 24 more

This is definitely not a pool exhausted situation, it is just being reported 
as pool exhausted. Since NoSuchElementException that you use does not allow 
cause, only Exception message (null) is being printed. With some debugging I 
was able to recover the root exception:

java.lang.NullPointerException
at 
org.apache.commons.dbcp.DelegatingConnection.setAutoCommit(DelegatingConnection.java:268)
at 
org.apache.commons.dbcp.PoolableConnectionFactory.activateObject(PoolableConnectionFactory.java:368)
at 
org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:786)
at 
org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:95)
at 
org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:540)
...

Looks like it is trying to borrow/validate DelegatingConnection which delegate 
is null.



Hoping to resolve the issue we upgraded to 1.2.2 but it did not help. Here is 
is an exception stack trace from 1.2.2:

org.apache.commons.dbcp.SQLNestedException: Cannot get a connection, pool error 
Could not create a validated

[jira] Created: (VFS-162) Url parsing incorrect with @ symbol in the password field.

2007-05-24 Thread Ivan Lazarte (JIRA)

Url parsing incorrect with @ symbol in the password field.
--

 Key: VFS-162
 URL: https://issues.apache.org/jira/browse/VFS-162
 Project: Commons VFS
  Issue Type: Bug
Affects Versions: 1.0
 Environment: N/A
Reporter: Ivan Lazarte


The file system being used used is SftpFileSystem.  After an initial look into, 
I'd have to subclass and invoke the Jsch libs directly to potentially set the 
pw programmatically?  It'd be nice if Sftp could accept a high level, non api 
specific method for programmatically setting the pw.  

Expected behavior is to choose the rightmost @ as the host delimiter, but a 
higher level programmatic api is a nice to have as well.
If I've missed anything in the api which lets me do this already, just let me 
know! :)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (LANG-336) Finally start using generics.

[
https://issues.apache.org/jira/browse/LANG-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498737
]

Henri Yandell commented on LANG-336:

Check out:

http://svn.apache.org/repos/asf/jakarta/commons/proper/lang/branches/LangTwo-1.x/

It's an experimental version of Lang that is intended to be 1.5+ (or maybe 1.6+
if there's cause). Currently it's not generified, so any help there would be
much appreciated. Your work from above should map pretty easily over, all I've
done so far is to cull the deprecated packages and methods.

Your patch didn't work btw.

Finally start using generics.
-

Key: LANG-336
URL: https://issues.apache.org/jira/browse/LANG-336
Project: Commons Lang
Issue Type: Improvement
Affects Versions: 2.3
Reporter: Hendrik Maryns
Attachments: commons-lang-2.3-sources-generic.tar.gz, lang.patch

It is obvious that the Jakarta project is reluctant in starting to use the
'new' (how old is it by now?) generics feature of Java. Nevertheless some
other people would like to see it incorporated in the commons projects.
I adapted commons Lang to usee generics. Took me about an afternoon. Would
be nice if something is done with it, except for only me using it in my
projects.
Some stuff will have to be changed to conform to guidelines and stuff.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (LANG-336) Finally start using generics.


[ 
https://issues.apache.org/jira/browse/LANG-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498754
 ] 

Henri Yandell commented on LANG-336:



I wonder if this kind of method can be legal...

public ObjectT[] foo(T ... t) {

}

Must play.

Btw, don't just blindly generify things, rethink APIs if it makes sense. We do 
need to keep a lot of our primitive stuff in NumberUtils etc; I imagine there's 
enough of a performance loss in autoboxing to make us not want to blindly use 
that in many places.

 Finally start using generics.
 -

 Key: LANG-336
 URL: https://issues.apache.org/jira/browse/LANG-336
 Project: Commons Lang
  Issue Type: Improvement
Affects Versions: 2.3
Reporter: Hendrik Maryns
 Attachments: commons-lang-2.3-sources-generic.tar.gz, lang.patch


 It is obvious that the Jakarta  project is reluctant in starting to use the 
 'new' (how old is it by now?) generics feature of Java.  Nevertheless some 
 other people would like to see it incorporated in the commons projects.
 I adapted commons Lang to usee generics.  Took me about an afternoon.  Would 
 be nice if something is done with it, except for only me using it in my 
 projects.
 Some stuff will have to be changed to conform to guidelines and stuff.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (LANG-336) Finally start using generics.

2007-05-24 Thread Tom Nichols (JIRA)


[ 
https://issues.apache.org/jira/browse/LANG-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498772
 ] 

Tom Nichols commented on LANG-336:
--

Henri Yandell [24/May/07 11:12 AM]:
I wonder if this kind of method can be legal...
public ObjectT[] foo(T ... t) { 

Don't you mean:
public T[] foo( T... t ) { ... }   ?  or  public ClassT[] foo( T... t ) { ... 
}  ?  

Object doesn't take any generic parameters...

 Finally start using generics.
 -

 Key: LANG-336
 URL: https://issues.apache.org/jira/browse/LANG-336
 Project: Commons Lang
  Issue Type: Improvement
Affects Versions: 2.3
Reporter: Hendrik Maryns
 Attachments: commons-lang-2.3-sources-generic.tar.gz, lang.patch


 It is obvious that the Jakarta  project is reluctant in starting to use the 
 'new' (how old is it by now?) generics feature of Java.  Nevertheless some 
 other people would like to see it incorporated in the commons projects.
 I adapted commons Lang to usee generics.  Took me about an afternoon.  Would 
 be nice if something is done with it, except for only me using it in my 
 projects.
 Some stuff will have to be changed to conform to guidelines and stuff.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r541397 - /jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/PropertyUtilsTestCase.java

Author: niallp
Date: Thu May 24 12:22:03 2007
New Revision: 541397

URL: http://svn.apache.org/viewvc?view=revrev=541397
Log:
Adding a test case for BEANUTILS-33 to PropertyUtilsTestCase. This incosistency 
(can't use dot in mapped properties for setProperty or getPropertyDescriptor) 
has already been fixed by the changes for BEANUTILS-259 (Plugable Property Name 
Expression Resolver)

Modified:

jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/PropertyUtilsTestCase.java

Modified: 
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/PropertyUtilsTestCase.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/PropertyUtilsTestCase.java?view=diffrev=541397r1=541396r2=541397
==
--- 
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/PropertyUtilsTestCase.java
 (original)
+++ 
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/PropertyUtilsTestCase.java
 Thu May 24 12:22:03 2007
@@ -439,6 +439,45 @@
 
 }
 
+/**
+ * Test getting mapped descriptor with periods in the key.
+ */
+public void testGetDescriptorMappedPeriods() {
+
+bean.getMappedIntProperty(xyz); // initializes mappedIntProperty
+
+PropertyDescriptor desc;
+Integer testIntegerValue = new Integer(1234);
+
+bean.setMappedIntProperty(key.with.a.dot, 
testIntegerValue.intValue());
+assertEquals(Can retrieve directly,
+ testIntegerValue,
+ new Integer(bean.getMappedIntProperty(key.with.a.dot)));
+try {
+desc = PropertyUtils.getPropertyDescriptor
+ (bean, mappedIntProperty(key.with.a.dot));
+assertEquals(Check descriptor type (A),
+ Integer.TYPE,
+ 
((MappedPropertyDescriptor)desc).getMappedPropertyType());
+} catch (Exception e) {
+fail(Threw exception (A):  + e);
+}
+
+bean.setMappedObjects(nested.property, new 
TestBean(testIntegerValue.intValue()));
+assertEquals(Can retrieve directly,
+  testIntegerValue,
+  new 
Integer(((TestBean)bean.getMappedObjects(nested.property)).getIntProperty()));
+try {
+desc = PropertyUtils.getPropertyDescriptor
+ (bean, mappedObjects(nested.property).intProperty);
+assertEquals(Check descriptor type (B),
+ Integer.TYPE,
+ desc.getPropertyType());
+} catch (Exception e) {
+fail(Threw exception (B):  + e);
+}
+}
+
 
 /**
  * Positive getPropertyDescriptor on property
@@ -2774,7 +2813,77 @@
 
 }
 
+/**
+ * Test setting mapped values with periods in the key.
+ */
+public void testSetMappedPeriods() {
+
+
+//  PropertyUtils.setMappedProperty()
+bean.setMappedProperty(key.with.a.dot, Special Value);
+assertEquals(Can retrieve directly (A),
+ Special Value,
+ bean.getMappedProperty(key.with.a.dot));
+
+try {
+PropertyUtils.setMappedProperty(bean, mappedProperty, 
key.with.a.dot, Updated Special Value);
+assertEquals(Check set via setMappedProperty,
+ Updated Special Value,
+  bean.getMappedProperty(key.with.a.dot));
+} catch (Exception e) {
+fail(Thew exception:  + e);
+}
+
+//  PropertyUtils.setNestedProperty() 
+bean.setMappedProperty(key.with.a.dot, Special Value);
+assertEquals(Can retrieve directly (B),
+ Special Value,
+ bean.getMappedProperty(key.with.a.dot));
+try {
+PropertyUtils.setNestedProperty(bean, 
mappedProperty(key.with.a.dot), Updated Special Value);
+assertEquals(Check set via setNestedProperty (B),
+ Updated Special Value,
+ bean.getMappedProperty(key.with.a.dot));
+} catch (Exception e) {
+fail(Thew exception:  + e);
+}
+
+
+//  PropertyUtils.setNestedProperty() 
+TestBean testBean = new TestBean();
+bean.setMappedObjects(nested.property, testBean);
+assertEquals(Can retrieve directly (C),
+ This is a string,
+ testBean.getStringProperty()); 
+try {
+PropertyUtils.setNestedProperty(bean, 
mappedObjects(nested.property).stringProperty,
+  Updated String Value);
+assertEquals(Check set via setNestedProperty (C),
+ Updated String Value,
+

[jira] Commented: (LANG-336) Finally start using generics.


[ 
https://issues.apache.org/jira/browse/LANG-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498791
 ] 

Henri Yandell commented on LANG-336:


Rethinks I suspect I went too far.

Here's my thought process:

* We should add varargs to some of our XxxUtils methods.
* We need closures, so we don't have T[] versions of T methods that just loop 
over the T[] and implement.
* How do varargs and Object[] work. Need to play.
* That got me into thinking the above :)

Varargs seem a bit lame in that we don't have tuple returns. So you can't do:

public String... capitalize(String ... input);

Not that that would make for nice programming. The LHS would be evil.

So first question to work out is... what parts of Lang would benefit from 
varargs. Seems that it'll only be ones that return void, or where the return 
type is an aggregation of the input and not a 1:1 mapping. Whether things need 
generifying would then follow from there.

 Finally start using generics.
 -

 Key: LANG-336
 URL: https://issues.apache.org/jira/browse/LANG-336
 Project: Commons Lang
  Issue Type: Improvement
Affects Versions: 2.3
Reporter: Hendrik Maryns
 Attachments: commons-lang-2.3-sources-generic.tar.gz, lang.patch


 It is obvious that the Jakarta  project is reluctant in starting to use the 
 'new' (how old is it by now?) generics feature of Java.  Nevertheless some 
 other people would like to see it incorporated in the commons projects.
 I adapted commons Lang to usee generics.  Took me about an afternoon.  Would 
 be nice if something is done with it, except for only me using it in my 
 projects.
 Some stuff will have to be changed to conform to guidelines and stuff.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (BEANUTILS-185) New Map decorator for DynaBeans to allow BeanUtils to operate with technologies such as JSTL


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton updated BEANUTILS-185:
--

Summary: New Map decorator for DynaBeans to allow BeanUtils to operate with 
technologies such as JSTL  (was: Try to align BeanUtils with JSTL standard tags)

 New Map decorator for DynaBeans to allow BeanUtils to operate with 
 technologies such as JSTL
 

 Key: BEANUTILS-185
 URL: https://issues.apache.org/jira/browse/BEANUTILS-185
 Project: Commons BeanUtils
  Issue Type: Improvement
  Components: DynaBean
Affects Versions: 1.7.0
 Environment: Operating System: other
 Platform: Other
Reporter: Gabriel Belingueres
 Assigned To: Niall Pemberton
Priority: Minor
 Fix For: 1.8.0

 Attachments: AbstractRowSetDynaClass.java, 
 BasicDirectAccessDynaBean.java, BasicDirectAccessDynaBeanTestCase.java, 
 BasicIndirectAccessDynaBean.java, beanutil-diff.txt, 
 DirectAccessDynaBean.java, DirectRowSetDynaClass.java, 
 DynaBeanMapDecorator.java, DynaBeanMapDecoratorTestCase.java, 
 IndirectAccessDynaBean.java, IndirectRowSetDynaClass.java


 Hi,
 I've done some modifications to the beanutils package to better support the 
 use 
 of DynaBeans with the JSTL tags. Some of the changes are discussed in this 
 thread of the commons-user mailing list:
 http://marc.theaimsgroup.com/?l=jakarta-commons-userm=114669123403779w=2
 I attach the diff file that comprises changes to the RowSetDynaClass.java 
 file 
 and build.xml file (since I added a TestCase.) Note: Please try to filter 
 carefully the diffs in the build.xml file since they include some local 
 settings I have for compilation on my machine. :-(
 Together with the diff file, I attach the new java files added to the package.
 Regards,
 Gabriel Belingueres
 [EMAIL PROTECTED]

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (LANG-336) Finally start using generics.

2007-05-24 Thread Tom Nichols (JIRA)


[ 
https://issues.apache.org/jira/browse/LANG-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498797
 ] 

Tom Nichols commented on LANG-336:
--

Henri Yandell [24/May/07 12:35 PM]
what parts of Lang would benefit from varargs

Parts wherever you will have one or more parameter of the same type.  Probably 
places where you currently pass in a String[] or Object[].  The reason being 
that previously, if you only had one parameter, you had to do 
foo( new Object[] { bar } );

If the method signature uses var args you can now pass an array OR 
foo( bar ); //or foo( bar, baz );

String.format( String s, Object... args )  is a classic example of its 
usefulness.

Another thing to consider is with var args *I believe* you will _always_ get an 
array instance passed in, whereas before you might have to do a null check:
foo( Object[] bar ) {
  if( bar == null ) throw new IllegalArgumentException( ... );
}

foo( Object... bar ) {
  for( Object o : bar ) // bar will never be null.
}

 Finally start using generics.
 -

 Key: LANG-336
 URL: https://issues.apache.org/jira/browse/LANG-336
 Project: Commons Lang
  Issue Type: Improvement
Affects Versions: 2.3
Reporter: Hendrik Maryns
 Attachments: commons-lang-2.3-sources-generic.tar.gz, lang.patch


 It is obvious that the Jakarta  project is reluctant in starting to use the 
 'new' (how old is it by now?) generics feature of Java.  Nevertheless some 
 other people would like to see it incorporated in the commons projects.
 I adapted commons Lang to usee generics.  Took me about an afternoon.  Would 
 be nice if something is done with it, except for only me using it in my 
 projects.
 Some stuff will have to be changed to conform to guidelines and stuff.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (CLI-71) [cli] A weakness of parser


[ 
https://issues.apache.org/jira/browse/CLI-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498798
 ] 

Henri Yandell commented on CLI-71:
--

Cool - independent confirmation :) I'll get the patch applied today and then 
it's time to start thinking about a release.

 [cli] A weakness of parser
 --

 Key: CLI-71
 URL: https://issues.apache.org/jira/browse/CLI-71
 Project: Commons CLI
  Issue Type: Bug
  Components: CLI-1.x
 Environment: Operating System: other
 Platform: All
Reporter: Amro Al-Akkad
 Fix For: 1.1

 Attachments: BugCLI71Test.java, BugCLI71Test.java, 
 CLI-71-badfix.patch, CLI-71-fix.patch, CLI71_resetvalues.patch, 
 Cloneable.patch, TestCommonsCLI.java


 I found a weakness of Jakarta Commons CLI and want to explain it with a simple
 example: 
 Our program provides 2 options: 
 1.-a or --algo name: The -a option requires an argument.
 2.-k or --key value: The -k option requires an argument too.
 a)
 If you pass the following command line arguments everything will be ok:
 -a Caesar -k A
 After evaluation:
 • Caesar is the parameter of the -a option and
 • A is the parameter of the -k option.
 b)
 However an org.apache.commons.cli.MissingArgumentException: no argument for:k 
 is
 thrown if you pass the following input:
 -a Caesar -k a
 The Parser assumes that the argument a after the -k option, is the -a option
 missing the hyphen. At the end of this description there is Java code for
 executing this problem.
 Information:
 The handling of this command line 
 -a Caesar -k a 
 works in Getopt without any problem:
 • Caesar is the parameter of the -a option and
 • a of the -k option.
 After parsing a valid option Getopt always takes the next (available) command
 line argument as the option's parameter if the option requires an argument -
 means if you pass to the command line 
 -k -a Caesar
 After evaluation:
 • a is the parameter of the -k option
 • the Caesar argument is just ignored
 If the option's parameter (value) represents an optional argument the next
 argument is not required, if it represents a valid option - means if you pass 
 to
 the command line 
 -k -a Caesar
 After evaluation:
 • Caesar is the parameter of the -a option
 • k option is set without a parameter - in this case a default value 
 makes sense.
 Last but not least here is the code snippet for the CLI Test:
 import org.apache.commons.cli.CommandLine;
 import org.apache.commons.cli.CommandLineParser;
 import org.apache.commons.cli.Option;
 import org.apache.commons.cli.Options;
 import org.apache.commons.cli.ParseException;
 import org.apache.commons.cli.PosixParser;
 public class TestCommonsCLI {
   /**
* @param args
*/
   public static void main(String[] args) {
   
   Options options = new Options();
   
   Option algorithm = new Option(a , algo, true, the 
 algorithm which it to
 perform executing);
   algorithm.setArgName(algorithm name);
   options.addOption(algorithm);
   
   Option key = new Option(k , key, true, the key the setted 
 algorithm uses
 to process);
   algorithm.setArgName(value);
   options.addOption(key);
   
   CommandLineParser parser = new PosixParser();
   
try {
   CommandLine line = parser.parse( options, args);
   
   if(line.hasOption('a')){
   System.out.println(algo: + line.getOptionValue( a 
 ));
   }
   
   if(line.hasOption('k')){
   System.out.println(key:  + line.getOptionValue('k'));
   }
   
   
   } catch (ParseException e) {
   // TODO Auto-generated catch block
   e.printStackTrace();
   }
   }
 }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r541407 - in /jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration: ConfigurationAssert.java FileURLStreamHandler.java

2007-05-24 Thread oheger

Author: oheger
Date: Thu May 24 13:03:09 2007
New Revision: 541407

URL: http://svn.apache.org/viewvc?view=revrev=541407
Log:
Added missing svn properties (may cause a large diff)

Modified:

jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/ConfigurationAssert.java
   (contents, props changed)

jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/FileURLStreamHandler.java
   (contents, props changed)

Modified: 
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/ConfigurationAssert.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/ConfigurationAssert.java?view=diffrev=541407r1=541406r2=541407
==
--- 
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/ConfigurationAssert.java
 (original)
+++ 
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/ConfigurationAssert.java
 Thu May 24 13:03:09 2007
@@ -1,49 +1,49 @@
-/*
- * Licensed to the Apache Software Foundation (ASF) under one or more
- * contributor license agreements.  See the NOTICE file distributed with
- * this work for additional information regarding copyright ownership.
- * The ASF licenses this file to You under the Apache License, Version 2.0
- * (the License); you may not use this file except in compliance with
- * the License.  You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an AS IS BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- * See the License for the specific language governing permissions and
- * limitations under the License.
- */
-
-package org.apache.commons.configuration;
-
-import java.util.Iterator;
-
-import junit.framework.Assert;
-
-/**
- * Assertions on configurations for the unit tests.
- * 
- * @author Emmanuel Bourg
- * @version $Revision$, $Date$
- */
-public class ConfigurationAssert
-{
-public static void assertEquals(Configuration expected, Configuration 
actual)
-{
-// check that the actual configuration contains all the properties of 
the expected configuration
-for (Iterator it = expected.getKeys(); it.hasNext();)
-{
-String key = (String) it.next();
-Assert.assertTrue(The actual configuration doesn't contain the 
expected key ' + key + ', actual.containsKey(key));
-Assert.assertEquals(Value of the ' + key + ' property, 
expected.getProperty(key), actual.getProperty(key));
-}
-
-// check that the actual configuration has no extra properties
-for (Iterator it = actual.getKeys(); it.hasNext();)
-{
-String key = (String) it.next();
-Assert.assertTrue(The actual configuration contains an extra key 
' + key + ', expected.containsKey(key));
-}
-}
-}
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the License); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.commons.configuration;
+
+import java.util.Iterator;
+
+import junit.framework.Assert;
+
+/**
+ * Assertions on configurations for the unit tests.
+ * 
+ * @author Emmanuel Bourg
+ * @version $Revision$, $Date$
+ */
+public class ConfigurationAssert
+{
+public static void assertEquals(Configuration expected, Configuration 
actual)
+{
+// check that the actual configuration contains all the properties of 
the expected configuration
+for (Iterator it = expected.getKeys(); it.hasNext();)
+{
+String key = (String) it.next();
+Assert.assertTrue(The actual configuration doesn't contain the 
expected key ' + key + ', actual.containsKey(key));
+Assert.assertEquals(Value of the ' + key + ' property, 
expected.getProperty(key), actual.getProperty(key));
+}
+
+// check that the actual configuration has no extra properties
+for (Iterator it = actual.getKeys(); it.hasNext();)
+{
+String key =

[jira] Commented: (VFS-162) Url parsing incorrect with @ symbol in the password field.

2007-05-24 Thread Ivan Lazarte (JIRA)


[ 
https://issues.apache.org/jira/browse/VFS-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498801
 ] 

Ivan Lazarte commented on VFS-162:
--

Here is my first pass fix in: SftpFileNameParser

@Override
protected String extractUserInfo(StringBuffer name) {

int pos = name.lastIndexOf(@);

if (pos  0) {
return null;
}

String userInfo = name.substring(0, pos);
name.delete(0, pos + 1);

if (userInfo.contains(/) || userInfo.contains(?)) {
return null;
}

return userInfo;
}

I believe this does the same thing logically as the originally except it looks 
for the last index.  However, I'm having a hard time getting a valid filesystem 
instance out of this- the path to integration is unclear to me.  If someone 
could advise a workaround, that would be really helpful.  

Thanks!

 Url parsing incorrect with @ symbol in the password field.
 --

 Key: VFS-162
 URL: https://issues.apache.org/jira/browse/VFS-162
 Project: Commons VFS
  Issue Type: Bug
Affects Versions: 1.0
 Environment: N/A
Reporter: Ivan Lazarte

 The file system being used used is SftpFileSystem.  After an initial look 
 into, I'd have to subclass and invoke the Jsch libs directly to potentially 
 set the pw programmatically?  It'd be nice if Sftp could accept a high level, 
 non api specific method for programmatically setting the pw.  
 Expected behavior is to choose the rightmost @ as the host delimiter, but a 
 higher level programmatic api is a nice to have as well.
 If I've missed anything in the api which lets me do this already, just let me 
 know! :)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r541408 - in /jakarta/commons/proper/cli/branches/cli-1.0.x/src: java/org/apache/commons/cli/Option.java java/org/apache/commons/cli/Parser.java test/org/apache/commons/cli/OptionTest.java

Author: bayard
Date: Thu May 24 13:07:06 2007
New Revision: 541408

URL: http://svn.apache.org/viewvc?view=revrev=541408
Log:
Applying Brian Egge and my work from CLI-71 to fix a lingering data problem in 
the parser and to confirm that other bugs have already been fixed

Added:

jakarta/commons/proper/cli/branches/cli-1.0.x/src/test/org/apache/commons/cli/OptionTest.java

jakarta/commons/proper/cli/branches/cli-1.0.x/src/test/org/apache/commons/cli/bug/BugCLI71Test.java
Modified:

jakarta/commons/proper/cli/branches/cli-1.0.x/src/java/org/apache/commons/cli/Option.java

jakarta/commons/proper/cli/branches/cli-1.0.x/src/java/org/apache/commons/cli/Parser.java

Modified: 
jakarta/commons/proper/cli/branches/cli-1.0.x/src/java/org/apache/commons/cli/Option.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/cli/branches/cli-1.0.x/src/java/org/apache/commons/cli/Option.java?view=diffrev=541408r1=541407r2=541408
==
--- 
jakarta/commons/proper/cli/branches/cli-1.0.x/src/java/org/apache/commons/cli/Option.java
 (original)
+++ 
jakarta/commons/proper/cli/branches/cli-1.0.x/src/java/org/apache/commons/cli/Option.java
 Thu May 24 13:07:06 2007
@@ -631,4 +631,15 @@
 return result;
 }
 
+/**
+ * pClear the Option values. After a 
+ * parse is complete, these are left with data in them 
+ * and they need clearing if another parse is done. /p
+ *
+ * See: a href=https://issues.apache.org/jira/browse/CLI-71;CLI-71/a
+ */
+void clearValues() {
+this.values.clear();
+}
+
 }

Modified: 
jakarta/commons/proper/cli/branches/cli-1.0.x/src/java/org/apache/commons/cli/Parser.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/cli/branches/cli-1.0.x/src/java/org/apache/commons/cli/Parser.java?view=diffrev=541408r1=541407r2=541408
==
--- 
jakarta/commons/proper/cli/branches/cli-1.0.x/src/java/org/apache/commons/cli/Parser.java
 (original)
+++ 
jakarta/commons/proper/cli/branches/cli-1.0.x/src/java/org/apache/commons/cli/Parser.java
 Thu May 24 13:07:06 2007
@@ -132,6 +132,13 @@
 {
 // initialise members
 this.options = options;
+
+// clear out the data in options in case it's been used before (CLI-71)
+for (Iterator it = options.helpOptions().iterator(); it.hasNext();) {
+Option opt = (Option) it.next();
+opt.clearValues();
+}
+
 requiredOptions = options.getRequiredOptions();
 cmd = new CommandLine();
 
@@ -403,4 +410,4 @@
 // set the option on the command line
 cmd.addOption(opt);
 }
-}
\ No newline at end of file
+}

Added: 
jakarta/commons/proper/cli/branches/cli-1.0.x/src/test/org/apache/commons/cli/OptionTest.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/cli/branches/cli-1.0.x/src/test/org/apache/commons/cli/OptionTest.java?view=autorev=541408
==
--- 
jakarta/commons/proper/cli/branches/cli-1.0.x/src/test/org/apache/commons/cli/OptionTest.java
 (added)
+++ 
jakarta/commons/proper/cli/branches/cli-1.0.x/src/test/org/apache/commons/cli/OptionTest.java
 Thu May 24 13:07:06 2007
@@ -0,0 +1,35 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the License); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.cli;
+
+import junit.framework.TestCase;
+
+/**
+ * @author brianegge
+ */
+public class OptionTest extends TestCase {
+
+   public void testClear() {
+   Option option = new Option(x, true, );
+   assertEquals(0, option.getValuesList().size());
+   option.addValue(a);
+   assertEquals(1, option.getValuesList().size());
+   option.clearValues();
+   assertEquals(0, option.getValuesList().size());
+   }
+
+}

Added: 
jakarta/commons/proper/cli/branches/cli-1.0.x/src/test/org/apache/commons/cli/bug/BugCLI71Test.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/cli/branches/cli-1.0.x/src/test/org/apache/commons/cli/bug/BugCLI71Test.java?view=autorev=541408
==
---

[jira] Closed: (CLI-71) [cli] A weakness of parser


 [ 
https://issues.apache.org/jira/browse/CLI-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Henri Yandell closed CLI-71.


Resolution: Fixed

 svn ci -m Applying Brian Egge and my work from CLI-71 to fix a lingering data 
problem in the parser and to confirm that other bugs have already been fixed 
src/

Sendingsrc/java/org/apache/commons/cli/Option.java
Sendingsrc/java/org/apache/commons/cli/Parser.java
Adding src/test/org/apache/commons/cli/OptionTest.java
Adding src/test/org/apache/commons/cli/bug/BugCLI71Test.java
Transmitting file data 
Committed revision 541408.

 [cli] A weakness of parser
 --

 Key: CLI-71
 URL: https://issues.apache.org/jira/browse/CLI-71
 Project: Commons CLI
  Issue Type: Bug
  Components: CLI-1.x
 Environment: Operating System: other
 Platform: All
Reporter: Amro Al-Akkad
 Fix For: 1.1

 Attachments: BugCLI71Test.java, BugCLI71Test.java, 
 CLI-71-badfix.patch, CLI-71-fix.patch, CLI71_resetvalues.patch, 
 Cloneable.patch, TestCommonsCLI.java


 I found a weakness of Jakarta Commons CLI and want to explain it with a simple
 example: 
 Our program provides 2 options: 
 1.-a or --algo name: The -a option requires an argument.
 2.-k or --key value: The -k option requires an argument too.
 a)
 If you pass the following command line arguments everything will be ok:
 -a Caesar -k A
 After evaluation:
 • Caesar is the parameter of the -a option and
 • A is the parameter of the -k option.
 b)
 However an org.apache.commons.cli.MissingArgumentException: no argument for:k 
 is
 thrown if you pass the following input:
 -a Caesar -k a
 The Parser assumes that the argument a after the -k option, is the -a option
 missing the hyphen. At the end of this description there is Java code for
 executing this problem.
 Information:
 The handling of this command line 
 -a Caesar -k a 
 works in Getopt without any problem:
 • Caesar is the parameter of the -a option and
 • a of the -k option.
 After parsing a valid option Getopt always takes the next (available) command
 line argument as the option's parameter if the option requires an argument -
 means if you pass to the command line 
 -k -a Caesar
 After evaluation:
 • a is the parameter of the -k option
 • the Caesar argument is just ignored
 If the option's parameter (value) represents an optional argument the next
 argument is not required, if it represents a valid option - means if you pass 
 to
 the command line 
 -k -a Caesar
 After evaluation:
 • Caesar is the parameter of the -a option
 • k option is set without a parameter - in this case a default value 
 makes sense.
 Last but not least here is the code snippet for the CLI Test:
 import org.apache.commons.cli.CommandLine;
 import org.apache.commons.cli.CommandLineParser;
 import org.apache.commons.cli.Option;
 import org.apache.commons.cli.Options;
 import org.apache.commons.cli.ParseException;
 import org.apache.commons.cli.PosixParser;
 public class TestCommonsCLI {
   /**
* @param args
*/
   public static void main(String[] args) {
   
   Options options = new Options();
   
   Option algorithm = new Option(a , algo, true, the 
 algorithm which it to
 perform executing);
   algorithm.setArgName(algorithm name);
   options.addOption(algorithm);
   
   Option key = new Option(k , key, true, the key the setted 
 algorithm uses
 to process);
   algorithm.setArgName(value);
   options.addOption(key);
   
   CommandLineParser parser = new PosixParser();
   
try {
   CommandLine line = parser.parse( options, args);
   
   if(line.hasOption('a')){
   System.out.println(algo: + line.getOptionValue( a 
 ));
   }
   
   if(line.hasOption('k')){
   System.out.println(key:  + line.getOptionValue('k'));
   }
   
   
   } catch (ParseException e) {
   // TODO Auto-generated catch block
   e.printStackTrace();
   }
   }
 }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r541411 - /jakarta/commons/proper/cli/dead/

Author: bayard
Date: Thu May 24 13:15:34 2007
New Revision: 541411

URL: http://svn.apache.org/viewvc?view=revrev=541411
Log:
Deleting in svn is easy to undo, but impossible to find that something was 
deleted later on so it really is very, very final. Dumping stuff here instead

Added:
jakarta/commons/proper/cli/dead/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r541412 - in /jakarta/commons/proper/cli: branches/commons-configuration-integration/ dead/commons-configuration-integration/

Author: bayard
Date: Thu May 24 13:16:05 2007
New Revision: 541412

URL: http://svn.apache.org/viewvc?view=revrev=541412
Log:
Dead branch

Added:
jakarta/commons/proper/cli/dead/commons-configuration-integration/
  - copied from r541411, 
jakarta/commons/proper/cli/branches/commons-configuration-integration/
Removed:
jakarta/commons/proper/cli/branches/commons-configuration-integration/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r541414 - in /jakarta/commons/proper/cli: branches/RESEARCH_CLI_2_ROXSPRING/ dead/RESEARCH_CLI_2_ROXSPRING/

Author: bayard
Date: Thu May 24 13:16:38 2007
New Revision: 541414

URL: http://svn.apache.org/viewvc?view=revrev=541414
Log:
Dead branch

Added:
jakarta/commons/proper/cli/dead/RESEARCH_CLI_2_ROXSPRING/
  - copied from r541413, 
jakarta/commons/proper/cli/branches/RESEARCH_CLI_2_ROXSPRING/
Removed:
jakarta/commons/proper/cli/branches/RESEARCH_CLI_2_ROXSPRING/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r541415 - in /jakarta/commons/proper/cli: branches/CLI_2_DEV_BRANCH/ dead/CLI_2_DEV_BRANCH/

Author: bayard
Date: Thu May 24 13:17:07 2007
New Revision: 541415

URL: http://svn.apache.org/viewvc?view=revrev=541415
Log:
Dead branch

Added:
jakarta/commons/proper/cli/dead/CLI_2_DEV_BRANCH/
  - copied from r541414, 
jakarta/commons/proper/cli/branches/CLI_2_DEV_BRANCH/
Removed:
jakarta/commons/proper/cli/branches/CLI_2_DEV_BRANCH/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r541416 - in /jakarta/commons/proper/cli: branches/CLI_1_BRANCH/ dead/CLI_1_BRANCH/

Author: bayard
Date: Thu May 24 13:17:36 2007
New Revision: 541416

URL: http://svn.apache.org/viewvc?view=revrev=541416
Log:
Dead branch

Added:
jakarta/commons/proper/cli/dead/CLI_1_BRANCH/
  - copied from r541415, jakarta/commons/proper/cli/branches/CLI_1_BRANCH/
Removed:
jakarta/commons/proper/cli/branches/CLI_1_BRANCH/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r541417 - in /jakarta/commons/proper/cli: branches/CLI_1_0_1_prepare/ dead/CLI_1_0_1_prepare/

Author: bayard
Date: Thu May 24 13:17:56 2007
New Revision: 541417

URL: http://svn.apache.org/viewvc?view=revrev=541417
Log:
Dead branch

Added:
jakarta/commons/proper/cli/dead/CLI_1_0_1_prepare/
  - copied from r541416, 
jakarta/commons/proper/cli/branches/CLI_1_0_1_prepare/
Removed:
jakarta/commons/proper/cli/branches/CLI_1_0_1_prepare/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r541418 - in /jakarta/commons/proper/cli: dead/Root_cli_1_x/ tags/Root_cli_1_x/

Author: bayard
Date: Thu May 24 13:18:28 2007
New Revision: 541418

URL: http://svn.apache.org/viewvc?view=revrev=541418
Log:
Dead tag

Added:
jakarta/commons/proper/cli/dead/Root_cli_1_x/
  - copied from r541417, jakarta/commons/proper/cli/tags/Root_cli_1_x/
Removed:
jakarta/commons/proper/cli/tags/Root_cli_1_x/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (BEANUTILS-233) Implement equals() and hashCode() methods for DynaProperty


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton updated BEANUTILS-233:
--

 Assignee: Niall Pemberton
Affects Version/s: (was: Nightly Builds)
   1.7.0
  Summary: Implement equals() and hashCode() methods for 
DynaProperty  (was: [beanutils] DynaProperty doesn't override equals or 
hashCode)

 Implement equals() and hashCode() methods for DynaProperty
 --

 Key: BEANUTILS-233
 URL: https://issues.apache.org/jira/browse/BEANUTILS-233
 Project: Commons BeanUtils
  Issue Type: Improvement
  Components: DynaBean
Affects Versions: 1.7.0
 Environment: Operating System: All
 Platform: All
Reporter: Russell
 Assigned To: Niall Pemberton
Priority: Minor
 Fix For: 1.8.0

 Attachments: DynaPropertyTestCase.java, patchfile.txt


 Meaningful implementations of these methods are necessary for implementing the
 same methods in classes that use DynaProperty. The reference equality test
 provided by Object is not useful in most cases.
 I have a patch and a new TestCase, but don't see a way to attach it on this 
 form.
 I wasn't sure about the build number either. I got the source from anonymous 
 svn.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[cli] Release time!

2007-05-24 Thread Henri Yandell


Thanks to the work of Brian Egge, we've finished with the CLI 1.x
issues and are ready for a 1.1 release *pause for wild cheers, ewoks
raining from the sky and other frivolousness*. It's been a while, 1.0
was released in late 2002.

Here's a quick braindump of thing to do for the release:

* Check with clirr to make sure we're binary compatible.
* Fix copyright headers [I'll volunteer to do that]
* Update documentation. Write release notes. Use JIRA's generated
notes as a starting point.
* Run RAT on things.
* Update site.
* Make an RC.

and many more besides I'm surefun.

Hen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (CONFIGURATION-274) PropertiesConfiguration.save() does not support escaping the escape character

2007-05-24 Thread Oliver Heger (JIRA)

PropertiesConfiguration.save() does not support escaping the escape character
-

 Key: CONFIGURATION-274
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-274
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.4
Reporter: Oliver Heger
 Assigned To: Oliver Heger
Priority: Minor
 Fix For: 1.5


When a new property is added to a PropertiesConfiguration, it is possible to 
escape the escaping character for list delimiters, e.g.

conf.addProperty(test.dirs, C:\\Temp,D:\\Data\\);

Here the Backslash after Temp must be escaped, otherwise the list delimiter 
won't be recognized. This works, but when the configuration is saved and loaded 
again, the backslash that escapes the escape character is dropped. The property 
is then treated as a single value property with an escaped list delimiter.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (BEANUTILS-33) Can't use dot in mapped properties for setProperty or getPropertyDescriptor


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton resolved BEANUTILS-33.
--

Resolution: Fixed

Part of the problem with BeanUtils was that the logic processing property names 
was duplciated in a number of places - and this bug is a result of 
inconsistency in different places. BEANUTILS-259 has abstracted this logic into 
a separate Resolver type and that has fixed this issue. I added a test case 
for property utils to make sure that it is fixed.

http://jakarta.apache.org/commons/beanutils/apidocs/org/apache/commons/beanutils/expression/package-summary.html

 Can't use dot in mapped properties for setProperty or getPropertyDescriptor
 -

 Key: BEANUTILS-33
 URL: https://issues.apache.org/jira/browse/BEANUTILS-33
 Project: Commons BeanUtils
  Issue Type: Bug
  Components: Expression Syntax
Affects Versions: 1.7.0
 Environment: Operating System: other
 Platform: Other
Reporter: Eoin Curran
 Fix For: 1.8.0

 Attachments: beanutils.dotsinmappedindices.patch, 
 PropertyUtilsMappedDot.txt, PropertyUtilsMappedIssues.txt, 
 PropertyUtilsTestCase1.txt, PropertyUtilsTestMappedDot.txt


 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10478
 fixed this problem for PropertyUtils.getProperty(); However, the problem 
 remains
 for setProperty and getPropertyDescriptor.
 I have fixed this against 1.6.1

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (CONFIGURATION-274) PropertiesConfiguration.save() does not support escaping the escape character

2007-05-24 Thread Oliver Heger (JIRA)


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oliver Heger resolved CONFIGURATION-274.


Resolution: Fixed

A fix has been committed.

 PropertiesConfiguration.save() does not support escaping the escape character
 -

 Key: CONFIGURATION-274
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-274
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.4
Reporter: Oliver Heger
 Assigned To: Oliver Heger
Priority: Minor
 Fix For: 1.5


 When a new property is added to a PropertiesConfiguration, it is possible to 
 escape the escaping character for list delimiters, e.g.
 conf.addProperty(test.dirs, C:\\Temp,D:\\Data\\);
 Here the Backslash after Temp must be escaped, otherwise the list delimiter 
 won't be recognized. This works, but when the configuration is saved and 
 loaded again, the backslash that escapes the escape character is dropped. The 
 property is then treated as a single value property with an escaped list 
 delimiter.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (BEANUTILS-185) New Map decorator for DynaBeans to allow BeanUtils to operate with technologies such as JSTL


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton resolved BEANUTILS-185.
---

Resolution: Fixed

http://jakarta.apache.org/commons/beanutils/apidocs/org/apache/commons/beanutils/DynaBeanMapDecorator.html

 New Map decorator for DynaBeans to allow BeanUtils to operate with 
 technologies such as JSTL
 

 Key: BEANUTILS-185
 URL: https://issues.apache.org/jira/browse/BEANUTILS-185
 Project: Commons BeanUtils
  Issue Type: Improvement
  Components: DynaBean
Affects Versions: 1.7.0
 Environment: Operating System: other
 Platform: Other
Reporter: Gabriel Belingueres
 Assigned To: Niall Pemberton
Priority: Minor
 Fix For: 1.8.0

 Attachments: AbstractRowSetDynaClass.java, 
 BasicDirectAccessDynaBean.java, BasicDirectAccessDynaBeanTestCase.java, 
 BasicIndirectAccessDynaBean.java, beanutil-diff.txt, 
 DirectAccessDynaBean.java, DirectRowSetDynaClass.java, 
 DynaBeanMapDecorator.java, DynaBeanMapDecoratorTestCase.java, 
 IndirectAccessDynaBean.java, IndirectRowSetDynaClass.java


 Hi,
 I've done some modifications to the beanutils package to better support the 
 use 
 of DynaBeans with the JSTL tags. Some of the changes are discussed in this 
 thread of the commons-user mailing list:
 http://marc.theaimsgroup.com/?l=jakarta-commons-userm=114669123403779w=2
 I attach the diff file that comprises changes to the RowSetDynaClass.java 
 file 
 and build.xml file (since I added a TestCase.) Note: Please try to filter 
 carefully the diffs in the build.xml file since they include some local 
 settings I have for compilation on my machine. :-(
 Together with the diff file, I attach the new java files added to the package.
 Regards,
 Gabriel Belingueres
 [EMAIL PROTECTED]

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r541424 - in /jakarta/commons/proper/beanutils/trunk: build.xml src/java/org/apache/commons/beanutils/DynaProperty.java src/test/org/apache/commons/beanutils/DynaPropertyTestCase.java

Author: niallp
Date: Thu May 24 13:45:24 2007
New Revision: 541424

URL: http://svn.apache.org/viewvc?view=revrev=541424
Log:
BEANUTILS-233 Implement equals() and hashCode() methods for DynaProperty - 
thanks to Russell for the patch and test case!

Added:

jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/DynaPropertyTestCase.java
   (with props)
Modified:
jakarta/commons/proper/beanutils/trunk/build.xml

jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/DynaProperty.java

Modified: jakarta/commons/proper/beanutils/trunk/build.xml
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/beanutils/trunk/build.xml?view=diffrev=541424r1=541423r2=541424
==
--- jakarta/commons/proper/beanutils/trunk/build.xml (original)
+++ jakarta/commons/proper/beanutils/trunk/build.xml Thu May 24 13:45:24 2007
@@ -272,6 +272,7 @@
 test.lazy.dynamap,
 test.lazy.dynalist,
 test.dynabean.mapdecorator,
+test.dynaproperty,
 test.indexed.properties,
 test.mapped.properties

@@ -540,6 +541,21 @@
   sysproperty key=org.apache.commons.logging.simplelog.defaultlog
  value=${test.level}/
   arg value=org.apache.commons.beanutils.LazyDynaBeanTestCase/
+  classpath refid=test.classpath/
+/java
+  /target
+
+  target name=test.dynaproperty depends=compile.tests
+echo message=Running DynaProperty tests .../
+java classname=${test.runner} fork=yes
+failonerror=${test.failonerror}
+  sysproperty key=org.apache.commons.logging.LogFactory
+ value=${test.factory}/
+  sysproperty key=org.apache.commons.logging.Log
+ value=${test.log}/
+  sysproperty key=org.apache.commons.logging.simplelog.defaultlog
+ value=${test.level}/
+  arg value=org.apache.commons.beanutils.DynaPropertyTestCase/
   classpath refid=test.classpath/
 /java
   /target

Modified: 
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/DynaProperty.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/DynaProperty.java?view=diffrev=541424r1=541423r2=541424
==
--- 
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/DynaProperty.java
 (original)
+++ 
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/DynaProperty.java
 Thu May 24 13:45:24 2007
@@ -201,6 +201,40 @@
 
 }
 
+/**
+ * Checks this instance against the specified Object for equality. 
Overrides the
+ * default refererence test for equality provided by [EMAIL PROTECTED] 
java.lang.Object#equals(Object)}  
+ */
+public boolean equals(final Object obj) {
+
+boolean result = false;
+
+result = (obj == this);
+
+if ((!result)  obj instanceof DynaProperty) {
+final DynaProperty that = (DynaProperty) obj;
+result = 
+   ((this.name == null) ? (that.name == null) : 
(this.name.equals(that.name))) 
+   ((this.type == null) ? (that.type == null) : 
(this.type.equals(that.type))) 
+   ((this.contentType == null) ? (that.contentType == null) : 
(this.contentType.equals(that.contentType)));
+}
+
+return result;
+}
+
+/**
+ * @see java.lang.Object#hashCode
+ */
+public int hashCode() {
+
+   int result = 1;
+   
+   result = result * 31 + ((name == null) ? 0 : name.hashCode());
+   result = result * 31 + ((type == null) ? 0 : type.hashCode());
+   result = result * 31 + ((contentType == null) ? 0 : 
contentType.hashCode());
+
+   return result;
+}
 
 /**
  * Return a String representation of this Object.

Added: 
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/DynaPropertyTestCase.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/DynaPropertyTestCase.java?view=autorev=541424
==
--- 
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/DynaPropertyTestCase.java
 (added)
+++ 
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/DynaPropertyTestCase.java
 Thu May 24 13:45:24 2007
@@ -0,0 +1,111 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under

[jira] Updated: (JELLY-272) Lots of defect links in website

2007-05-24 Thread Lukas Theussl (JIRA)

[
https://issues.apache.org/jira/browse/JELLY-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Lukas Theussl updated JELLY-272:

Attachment: JELLY-272.patch

Attaching a patch to fix the jelly site and make it build-able with Maven 1.1
(should work with 1.0.2 and upgraded plugins too, though).

Here's what I did:

- commented out the missing links under 'Tag reference', or replaced them with
direct links to the tags refs (I think these pages should really go into the
individual taglibs)

- replaced the checkstyle config file (it's now the same as the one used by
commons-lang) and simplified the pmd rule sets to speed up the build. Removed a
few reports I thought were pointless, and added some others (multichanges,
multiproject, jellydoc)

- I had to exclude the avalon taglib because it has the wrong directory
structure (sources are in o.a.c.jelly/avalon/ instead of
o.a.c.jelly/tags/avalon/), which makes the jellydoc plugin unhappy. This has
to be fixed in SVN.

- Replaced the custom goals in maven.xml that used to build the site by some
simple multiproject goals. The goals build-all-sites and deploy-all-sites can
be used to build and deploy the main site and all subprojects, the main site is
just built with multiproject:site.

- the sql taglib had a dependency on jdbc which I commented out because it is
not on ibiblio, but apparently isn't needed according to a comment.

- adjusted the whole site style according to
http://wiki.apache.org/jakarta-commons/MavenWebsiteStucture

The result is here: http://people.apache.org/~ltheussl/jelly/

Lots of defect links in website
---

Key: JELLY-272
URL: https://issues.apache.org/jira/browse/JELLY-272
Project: Commons Jelly
Issue Type: Bug
Environment: none
Reporter: Peter Büttner
Attachments: JELLY-272.patch

I found al lot of dead links in the jelly 'website', links to examples an a
lot
here: http://jakarta.apache.org/commons/jelly/tag-reference/index.html
e.g. this is dead
http://jakarta.apache.org/commons/jelly/tag-reference/bsf.html
and all of it sibling nodes.
Opening http://jakarta.apache.org/commons/jelly/tag-reference/all.html
and selecting any tagdoc shows a page, but with empty content.
I think the CMS is defect.
Greetings
Peter

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (VFS-98) VFS causes deadlocks or is not thread-safe

2007-05-24 Thread Chris Beams (JIRA)

[
https://issues.apache.org/jira/browse/VFS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498825
]

Chris Beams commented on VFS-98:

I assume that because this issue was resolved before the release date of
Commons VFS 1.0, that this fix is included in 1.0. However, the Fix Version is
not explicit about this, so I'm writing to make sure my assumption is correct.
I'm running into thread-related issues as well, and though I haven't pinpointed
them, they sound similar to those Juha-Matti was experiencing.

Thanks!

VFS causes deadlocks or is not thread-safe
--

Key: VFS-98
URL: https://issues.apache.org/jira/browse/VFS-98
Project: Commons VFS
Issue Type: Bug
Affects Versions: Nightly Builds
Environment: jdk1.5.0_07 / Linux
Reporter: Juha-Matti Toppinen
Assigned To: Mario Ivankovits
Attachments: vfs.dead.jstack.txt,
vfs.dead.threaddump.synchronizedfileobject.txt, vfs.dead.threaddump.txt

Newer versions of VFS seems to be unusable in multithreading environments,
causing a deadlock of some kind. This causes my Java web server application
to completely hang when there is many concurrent connections. My application
uses a single FileSystemManager instance, and makes quite heavy use of VFS;
opening many files from many threads simultaneously.
I have tried, without success different workarounds based on some mailing
list threads:
- Using both NullReferenceFilesCache and the default SoftReferenceFilesCache.
(SoftReferenceFilesCache seemed to sometimes cause some additional
thread-related exceptions under heavy load, but propably unrelated to this
issue)
- Using the new SynchorizedFileObjectDecorator also did not help. On the
contrary, it seemed to trigger the deadlock more easily.
The version I have problems with is a nightly build: commons-vfs-20060831
The older version commons-vfs-20060115 works beautifully, but I would like to
use newer version because I want to be able to use FileObject.refresh() to
reset the internal state of files (specially, to get a fresh list of
children).
I hope the threading issues are going to be resolved in near future, and I am
willing to help in any way. I do not have very deep experience about
multithreading applications, so I wasn't able to get more close to the roots
of the issue. Feel free to ask for more information.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (BEANUTILS-233) Implement equals() and hashCode() methods for DynaProperty


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton resolved BEANUTILS-233.
---

Resolution: Fixed

Thanks for the patch - always welcome and especially with test cases! I've 
applied this.

 Implement equals() and hashCode() methods for DynaProperty
 --

 Key: BEANUTILS-233
 URL: https://issues.apache.org/jira/browse/BEANUTILS-233
 Project: Commons BeanUtils
  Issue Type: Improvement
  Components: DynaBean
Affects Versions: 1.7.0
 Environment: Operating System: All
 Platform: All
Reporter: Russell
 Assigned To: Niall Pemberton
Priority: Minor
 Fix For: 1.8.0

 Attachments: DynaPropertyTestCase.java, patchfile.txt


 Meaningful implementations of these methods are necessary for implementing the
 same methods in classes that use DynaProperty. The reference equality test
 provided by Object is not useful in most cases.
 I have a patch and a new TestCase, but don't see a way to attach it on this 
 form.
 I wasn't sure about the build number either. I got the source from anonymous 
 svn.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (DIGESTER-113) Can sources attachment for Digester 1.8 be uploaded to Maven repo on ibiblio?


[ 
https://issues.apache.org/jira/browse/DIGESTER-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498829
 ] 

Henri Yandell commented on DIGESTER-113:


Sorry for the delay - jars are made. Just need to wait 'til I'm home to do the 
GPG signing.

 Can sources attachment for Digester 1.8 be uploaded to Maven repo on ibiblio?
 -

 Key: DIGESTER-113
 URL: https://issues.apache.org/jira/browse/DIGESTER-113
 Project: Commons Digester
  Issue Type: Wish
Affects Versions: 1.8
Reporter: Matt Whitlock
 Assigned To: Henri Yandell
Priority: Minor

 Please see http://jira.codehaus.org/browse/MAVENUPLOAD-1521 .
 I am supposed to ask if you will allow 
 http://www.mattwhitlock.com/commons-digester-1.8-sources.jar to be uploaded 
 to the Maven central repository on ibiblio as the source attachment for the 
 commons-digester:commons-digester:1.8:jar artifact.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (VFS-162) Url parsing incorrect with @ symbol in the password field.

2007-05-24 Thread Ivan Lazarte (JIRA)


 [ 
https://issues.apache.org/jira/browse/VFS-162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Lazarte updated VFS-162:
-

Attachment: vfs-bug-fix.zip

Attached is a workaround I've made and includes a demo main.  Feel free to edit 
as necessary.

 Url parsing incorrect with @ symbol in the password field.
 --

 Key: VFS-162
 URL: https://issues.apache.org/jira/browse/VFS-162
 Project: Commons VFS
  Issue Type: Bug
Affects Versions: 1.0
 Environment: N/A
Reporter: Ivan Lazarte
 Attachments: vfs-bug-fix.zip


 The file system being used used is SftpFileSystem.  After an initial look 
 into, I'd have to subclass and invoke the Jsch libs directly to potentially 
 set the pw programmatically?  It'd be nice if Sftp could accept a high level, 
 non api specific method for programmatically setting the pw.  
 Expected behavior is to choose the rightmost @ as the host delimiter, but a 
 higher level programmatic api is a nice to have as well.
 If I've missed anything in the api which lets me do this already, just let me 
 know! :)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r541445 - /jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/JXPathContextReferenceImpl.java

2007-05-24 Thread mbenson

Author: mbenson
Date: Thu May 24 15:03:00 2007
New Revision: 541445

URL: http://svn.apache.org/viewvc?view=revrev=541445
Log:
ws

Modified:

jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/JXPathContextReferenceImpl.java

Modified: 
jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/JXPathContextReferenceImpl.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/JXPathContextReferenceImpl.java?view=diffrev=541445r1=541444r2=541445
==
--- 
jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/JXPathContextReferenceImpl.java
 (original)
+++ 
jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/JXPathContextReferenceImpl.java
 Thu May 24 15:03:00 2007
@@ -154,7 +154,7 @@
 
 NamespaceResolver parentNR = null;
 if (parentContext instanceof JXPathContextReferenceImpl) {
-parentNR = 
((JXPathContextReferenceImpl)parentContext).getNamespaceResolver();
+parentNR = ((JXPathContextReferenceImpl) 
parentContext).getNamespaceResolver();
 }
 namespaceResolver = new NamespaceResolver(parentNR);
 namespaceResolver



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r541446 - /jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/NamespaceResolver.java

2007-05-24 Thread mbenson

Author: mbenson
Date: Thu May 24 15:04:39 2007
New Revision: 541446

URL: http://svn.apache.org/viewvc?view=revrev=541446
Log:
restore binary compat. w/ 1.2: JXPATH-85; javadoc

Modified:

jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/NamespaceResolver.java

Modified: 
jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/NamespaceResolver.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/NamespaceResolver.java?view=diffrev=541446r1=541445r2=541446
==
--- 
jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/NamespaceResolver.java
 (original)
+++ 
jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/NamespaceResolver.java
 Thu May 24 15:04:39 2007
@@ -16,7 +16,6 @@
  */
 package org.apache.commons.jxpath.ri;
 
-
 import java.util.HashMap;
 import java.util.Iterator;
 import java.util.Map;
@@ -26,7 +25,7 @@
 import org.apache.commons.jxpath.ri.model.NodePointer;
 
 /**
- * The reference implementation of JXPathContext.
+ * Namespace resolver for JXPathContextReferenceImpl.
  *
  * @author Dmitri Plotnikov
  * @version $Revision$ $Date$
@@ -37,7 +36,18 @@
 protected HashMap reverseMap;
 protected NodePointer pointer;
 private boolean sealed;
-
+
+/**
+ * Create a new NamespaceResolver.
+ */
+public NamespaceResolver() {
+this(null);
+}
+
+/**
+ * Create a new NamespaceResolver.
+ * @param parent
+ */
 public NamespaceResolver(NamespaceResolver parent) {
 this.parent = parent;
 }
@@ -55,11 +65,16 @@
 
 /**
  * Register a namespace for the expression context.
+ * @param pointer the Pointer to set.
  */
 public void setNamespaceContextPointer(NodePointer pointer) {
 this.pointer = pointer;
 }
-
+
+/**
+ * Get the namespace context pointer.
+ * @return Pointer
+ */
 public Pointer getNamespaceContextPointer() {
 if (pointer == null  parent != null) {
 return parent.getNamespaceContextPointer();
@@ -87,7 +102,12 @@
 }
 return uri;
 }
-
+
+/**
+ * Get the prefix associated with the specifed namespace URI.
+ * @param namespaceURI the ns URI to check.
+ * @return String prefix
+ */
 public String getPrefix(String namespaceURI) {
 if (reverseMap == null) {
 reverseMap = new HashMap();
@@ -114,18 +134,29 @@
 }
 return prefix;
 }
-
+
+/**
+ * Learn whether this NamespaceResolver has been sealed.
+ * @return
+ */
 public boolean isSealed() {
 return sealed;
 }
-
+
+/**
+ * Seal this [EMAIL PROTECTED] NamespaceResolver}.
+ */
 public void seal() {
 sealed = true;
 if (parent != null) {
 parent.seal();
 }
 }
-
+
+/**
+ * [EMAIL PROTECTED]
+ * @see java.lang.Object#clone()
+ */
 public Object clone() {
 try {
 return super.clone();



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (JXPATH-85) Restore binary compatibility with JXPath 1.2

2007-05-24 Thread Matt Benson (JIRA)


 [ 
https://issues.apache.org/jira/browse/JXPATH-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Benson resolved JXPATH-85.
---

Resolution: Fixed

Thanks for the report, Niall!  Fixed.

 Restore binary compatibility with JXPath 1.2
 

 Key: JXPATH-85
 URL: https://issues.apache.org/jira/browse/JXPATH-85
 Project: Commons JXPath
  Issue Type: Bug
Affects Versions: 1.2 Final
Reporter: Niall Pemberton
 Fix For: 1.3

 Attachments: jxpath-85.patch


 I ran a CLIRR report comparing JXPath 1.2 with the current trunk and it 
 higlighted one issue between the versions:
 ERROR: 7004: org.apache.commons.jxpath.ri.NamespaceResolver: In method 
 'public NamespaceResolver()' the number of arguments has changed
 Looking at the source NamespaceResolver no longer has a no-parameter 
 constructor - adding this back in would make the upcoming JXPath 1.3 version 
 binary compatible with JXPath 1.2.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (BEANUTILS-212) [beanutils] Generic implementations of toString, hashCode, equals() for DynaBean and DynaClass


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton updated BEANUTILS-212:
--

Affects Version/s: (was: Nightly Builds)
   1.7.0
Fix Version/s: (was: 1.8.0)
   LATER THAN 1.8.0

A few comments:

* I've applied the patch from BEANUTILS-233 which adds hashcode() and equals() 
implementations to DynaProperty.
* DynaUtils.buildHashCode(DynaBean) will throw a null pointer exception if the 
property value is null
* DynaUtils.buildHashCode(DynaBean) doesn't take into account the DynaBean 
implementation - seems to me like it should?
* DynaUtils.buildHashCode(DynaClass) doesn't take into account the DynaClass 
implementation - seems to me like it should?

I also think that implementing toString() is best done by the person using it - 
since how muchof little information they would want and the format is very much 
down to how its being used. Lang has a whole set of string builder classes 
which do this sort of thing so I'm inclinded to not implement any of this. 
Personally I have my own custom impl. that does this.

The other part of the problem is I don't understand the implications of 
hashCode() enough and my big fear is that it would screw things up - so I'm 
going to punt this for now to post 1.8.0. Apologies if, due to my 
shortcommings, this is annoying.


 [beanutils] Generic implementations of toString, hashCode, equals() for 
 DynaBean and DynaClass
 --

 Key: BEANUTILS-212
 URL: https://issues.apache.org/jira/browse/BEANUTILS-212
 Project: Commons BeanUtils
  Issue Type: Improvement
  Components: DynaBean
Affects Versions: 1.7.0
 Environment: Operating System: All
 Platform: All
Reporter: Kris Nuttycombe
Priority: Minor
 Fix For: LATER THAN 1.8.0

 Attachments: AbstractDynaBean.java, AbstractDynaClass.java, 
 DynaUtils.java, patch.txt


 This patchset includes a new DynaUtils class containing builder methods for 
 hash
 codes and string representations of DynaBeans and DynaClasses, abstract base
 classes for DynaBean and DynaClass that use DynaUtils to implement these
 methods, and patches for existing DynaBean and DynaClass implementations to 
 make
 them extend these abstract base classes.
 Kris

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jci] RC2 available

2007-05-24 Thread Torsten Curdt

On every release you (try to) do with maven you learn something new.  
That's great - isn't it? :p
Anyway... I am (finally) happy to announce that commmon-jci RC2 is  
available at


 http://people.apache.org/builds/jakarta-commons/jci/1.0-RC2/org/ 
apache/commons/commons-jci/1.0/
 http://people.apache.org/builds/jakarta-commons/jci/1.0-RC2/org/ 
apache/commons/commons-jci-core/1.0/
 http://people.apache.org/builds/jakarta-commons/jci/1.0-RC2/org/ 
apache/commons/commons-jci-fam/1.0/


 http://people.apache.org/builds/jakarta-commons/jci/1.0-RC2/org/ 
apache/commons/commons-jci-eclipse/1.0/
 http://people.apache.org/builds/jakarta-commons/jci/1.0-RC2/org/ 
apache/commons/commons-jci-groovy/1.0/
 http://people.apache.org/builds/jakarta-commons/jci/1.0-RC2/org/ 
apache/commons/commons-jci-janino/1.0/
 http://people.apache.org/builds/jakarta-commons/jci/1.0-RC2/org/ 
apache/commons/commons-jci-javac/1.0/
 http://people.apache.org/builds/jakarta-commons/jci/1.0-RC2/org/ 
apache/commons/commons-jci-rhino/1.0/


 http://people.apache.org/builds/jakarta-commons/jci/1.0-RC2/org/ 
apache/commons/commons-jci-examples/1.0/


Almost no code changes - mostly the packaging and the site has been  
fixed as requested. (We now also have the assembly instructions and  
*could* build a one-zip-to-rule-them-all distribution but I would  
rather not have that as an official release.)


Please check and let me know if you find something. If there aren't  
any objections I will start a vote on the weekend.


cheers
--
Torsten

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [cli] Release time!

2007-05-24 Thread Torsten Curdt


yay!!! :)

On 24.05.2007, at 22:38, Henri Yandell wrote:


Thanks to the work of Brian Egge, we've finished with the CLI 1.x
issues and are ready for a 1.1 release *pause for wild cheers, ewoks
raining from the sky and other frivolousness*. It's been a while, 1.0
was released in late 2002.

Here's a quick braindump of thing to do for the release:

* Check with clirr to make sure we're binary compatible.
* Fix copyright headers [I'll volunteer to do that]
* Update documentation. Write release notes. Use JIRA's generated
notes as a starting point.
* Run RAT on things.
* Update site.
* Make an RC.

and many more besides I'm surefun.

Hen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (BEANUTILS-247) Arrays with multiple dimension are not supported


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton updated BEANUTILS-247:
--

Component/s: (was: Bean / Property Utils)
 Expression Syntax

 Arrays with multiple dimension are not supported
 

 Key: BEANUTILS-247
 URL: https://issues.apache.org/jira/browse/BEANUTILS-247
 Project: Commons BeanUtils
  Issue Type: Bug
  Components: Expression Syntax
Affects Versions: 1.7.0
 Environment: I run BeanUtils on Windows XP with Eclipse 3.1.1.
Reporter: Christian Poitras
 Fix For: 1.8.0

 Attachments: beanerror.zip, PropertyUtilsBean.java


 When an array with multiple dimension is used, accessing and setting 
 properties is not supported.
 For instance, the call to PropertyUtils.getNestedProperty(myObject, 
 multiArray[0][0].id) fails since the second array index is never used.
 This raises the following exception.
 Exception in thread main java.lang.NoSuchMethodException: Unknown property 
 'id'
   at 
 org.apache.commons.beanutils.PropertyUtilsBean.getSimpleProperty(PropertyUtilsBean.java:1122)
   at 
 org.apache.commons.beanutils.PropertyUtilsBean.getNestedProperty(PropertyUtilsBean.java:686)
   at 
 org.apache.commons.beanutils.PropertyUtils.getNestedProperty(PropertyUtils.java:272)
   at Test.main(Test.java:24)
 The id property does exists in the object multiArray[0][0] and if I make 
 a call to multiArray[0][0].getId(), the correct value is returned.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (BEANUTILS-43) Mapped property inside a mapped property is not populated on submit