DO NOT REPLY [Bug 39140] - [cli] A weakness of parser
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=39140. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=39140 --- Additional Comments From [EMAIL PROTECTED] 2007-05-23 01:48 --- Nudge to make comments on the JIRA rather than Bugzilla - I know it sucks that we don't have a good way of closing things in Bugzilla. :( http://issues.apache.org/jira/browse/CLI-71 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - 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_12498156
]
Henri Yandell commented on CLI-71:
--
Comment from Bugzilla:
--- Additional Comment #2 From Amro Al-Akkad 2007-05-22 15:23 [reply]
---
Amro didn't flag the 'license for asf inclusion' checkbox
Sorry.
JUnit test based on Amro's description. As expected, it fails.
:(. When will this bug be fixed (approximately)?
Will this weakness exist, in the newer version, too?
[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, 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_12498157
]
Henri Yandell commented on CLI-71:
--
It's planned for this to be fixed in the 1.1 release, it's the last issue left
in the list. Someone just needs to figure out what the fix is :)
[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, 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]
[Jakarta-commons Wiki] Update of TLPResolution by DionGillard
Dear Wiki user, You have subscribed to a wiki page or wiki category on Jakarta-commons Wiki for change notification. The following page has been changed by DionGillard: http://wiki.apache.org/jakarta-commons/TLPResolution -- * Rory Winston rwinston at apache.org * Luc Maisonobe[EMAIL PROTECTED] * Joerg Pietschmann[EMAIL PROTECTED] + * Dion Gillard [EMAIL PROTECTED] NOW, THEREFORE, BE IT FURTHER RESOLVED, that Torsten Curdt be appointed to the office of Vice President, Commons, to serve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[io] Next release - was Re: [VOTE] 2nd attempt: Release commons-io 1.3.2
I would normally consider a minor point release to be essential bug fix only (in the numbering system we've been using). Perhaps, rather than trying to release 1.3.2, we should release [io] v1.4 (still JDK1.3 compatible). Stephen - Original Message From: Niall Pemberton [EMAIL PROTECTED] To: Jakarta Commons Developers List commons-dev@jakarta.apache.org Sent: Tuesday, 22 May, 2007 8:51:10 PM Subject: Re: [VOTE] 2nd attempt: Release commons-io 1.3.2 I committed a small patch to the trunk today (IO-121) - since this release seems delayed is there any objections to me porting this to the 1.3 branch so it makes the 1.3.2 release? https://issues.apache.org/jira/browse/IO-121 The change is v.small - just adding a new resetByteCount() method to ThresholdingOutputStream that has 2 lines in it. Niall On 5/17/07, Jochen Wiedmann [EMAIL PROTECTED] wrote: Hi, I have fixed the issues with the file permissions and added license headers to most of the files, with the only exception of MANIFEST.MF. Now, I'd like to call for another vote on the release of commons-io 1.3.2. The proposed distributables can be found at http://people.apache.org/~jochen/commons-io/dist A KEYS file is included. The proposed site is at http://people.apache.org/~jochen/commons-io/site Thanks, Jochen [ ] +1 [ ] =0 [ ] -1 -- My cats know that I am a loser who goes out for hunting every day without ever returning as much as a single mouse. Fortunately, I've got a wife who's a real champ: She leaves the house and returns within half an hour, carrying whole bags full of meal. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-id (in module jakarta-commons-sandbox) failed
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-id has an issue affecting its community integration. This issue affects 1 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-id : Commons Identifier Package Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-id/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-id-23052007.jar] identifier set to project name -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/id/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/id/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/id/project.properties -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-id/gump_work/build_jakarta-commons-sandbox_commons-id.html Work Name: build_jakarta-commons-sandbox_commons-id (Type: Build) Work ended in a state of : Failed Elapsed: 1 min 8 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/jakarta-commons-sandbox/id] 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/discovery/dist/commons-discovery.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-23052007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-23052007.jar:/usr/local/gump/public/workspace/junit/dist/junit-23052007.jar:/usr/local/gump/packages/maven-cobertura-plugin/maven-cobertura-plugin-1.1.jar:/usr/local/gump/packages/maven-xdoc-plugin/maven-xdoc-plugin-1.9.2.jar - [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 1.029 sec [junit] Running org.apache.commons.id.serial.PrefixedLeftPaddedNumericGeneratorTest [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.99 sec [junit] Running org.apache.commons.id.serial.TimeBasedAlphanumericIdentifierGeneratorTest [junit] Tests run: 12, Failures: 2, Errors: 0, Time elapsed: 1.568 sec [junit] [ERROR] TEST org.apache.commons.id.serial.TimeBasedAlphanumericIdentifierGeneratorTest FAILED [junit] Running org.apache.commons.id.serial.AlphanumericGeneratorTest [junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 1.051 sec [junit] Running org.apache.commons.id.serial.LongGeneratorTest [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 1.049 sec [junit] Running org.apache.commons.id.serial.NumericGeneratorTest [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 1.04 sec [junit] Running org.apache.commons.id.uuid.state.StateHelperTest [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 1.245 sec [junit] Running org.apache.commons.id.uuid.state.NodeTest [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 1.251 sec [junit] Running org.apache.commons.id.uuid.state.InMemoryStateImplTest [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 1.322 sec [junit] Running org.apache.commons.id.uuid.state.ReadOnlyResourceStateImplTest [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 1.551 sec [junit] Running org.apache.commons.id.uuid.state.ReadWriteFileStateImplTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.467 sec [junit] Running org.apache.commons.id.uuid.clock.SystemClockImplTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.981 sec [junit] Running org.apache.commons.id.uuid.clock.ThreadClockImplTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.994 sec [junit] Running org.apache.commons.id.uuid.NodeManagerImplTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.486 sec [junit] Running org.apache.commons.id.uuid.UUIDTest [junit] Tests run: 17, Failures:
[EMAIL PROTECTED]: Project commons-id (in module jakarta-commons-sandbox) failed
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-id has an issue affecting its community integration. This issue affects 1 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-id : Commons Identifier Package Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-id/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-id-23052007.jar] identifier set to project name -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/id/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/id/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/jakarta-commons-sandbox/id/project.properties -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-id/gump_work/build_jakarta-commons-sandbox_commons-id.html Work Name: build_jakarta-commons-sandbox_commons-id (Type: Build) Work ended in a state of : Failed Elapsed: 1 min 8 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/jakarta-commons-sandbox/id] 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/discovery/dist/commons-discovery.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-23052007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-23052007.jar:/usr/local/gump/public/workspace/junit/dist/junit-23052007.jar:/usr/local/gump/packages/maven-cobertura-plugin/maven-cobertura-plugin-1.1.jar:/usr/local/gump/packages/maven-xdoc-plugin/maven-xdoc-plugin-1.9.2.jar - [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 1.029 sec [junit] Running org.apache.commons.id.serial.PrefixedLeftPaddedNumericGeneratorTest [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.99 sec [junit] Running org.apache.commons.id.serial.TimeBasedAlphanumericIdentifierGeneratorTest [junit] Tests run: 12, Failures: 2, Errors: 0, Time elapsed: 1.568 sec [junit] [ERROR] TEST org.apache.commons.id.serial.TimeBasedAlphanumericIdentifierGeneratorTest FAILED [junit] Running org.apache.commons.id.serial.AlphanumericGeneratorTest [junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 1.051 sec [junit] Running org.apache.commons.id.serial.LongGeneratorTest [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 1.049 sec [junit] Running org.apache.commons.id.serial.NumericGeneratorTest [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 1.04 sec [junit] Running org.apache.commons.id.uuid.state.StateHelperTest [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 1.245 sec [junit] Running org.apache.commons.id.uuid.state.NodeTest [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 1.251 sec [junit] Running org.apache.commons.id.uuid.state.InMemoryStateImplTest [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 1.322 sec [junit] Running org.apache.commons.id.uuid.state.ReadOnlyResourceStateImplTest [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 1.551 sec [junit] Running org.apache.commons.id.uuid.state.ReadWriteFileStateImplTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.467 sec [junit] Running org.apache.commons.id.uuid.clock.SystemClockImplTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.981 sec [junit] Running org.apache.commons.id.uuid.clock.ThreadClockImplTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.994 sec [junit] Running org.apache.commons.id.uuid.NodeManagerImplTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.486 sec [junit] Running org.apache.commons.id.uuid.UUIDTest [junit] Tests run: 17, Failures:
[VFS] Support for cifs (smb) not in VFS 1.0
Hello, I used vfs-1.0-RC7 until now and it worked fine for me to get Files from an ftp server and write them to a smb server. Now I have to switch from ftp to sftp because of security reasons. So I tested with RC7 and ran into problems with threads holding the sftp session after closing the ressource. I got the hint to close the filesystem explicit with closeFileSystem(fs). closeFileSystem(fs) is not in RC7 so I checked out VFS 1.0 Final. But that doesn't contain smb (cifs) anymore. Can anybody tell me why cifs moved to sandbox? I would need both protocols to get my application running again. Mit freundlichen Grüßen Detlev Mörk Systementwickler Konradin Business GmbH Ernst-Mey-Str. 8 70771 Leinfelden-Echterdingen Tel.: +49 711/7594-504 Fax.: +49 711/7594-1504 Email: [EMAIL PROTECTED] Konradin Business GmbH Sitz der Gesellschaft: Ernst-Mey-Str. 8, 70771 Leinfelden- Echterdingen Amtsgericht Stuttgart HRB 224875 Geschäftsführer: Katja Kohlhammer, Peter Dilger - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS] Support for cifs (smb) not in VFS 1.0
Hi! But that doesn't contain smb (cifs) anymore. Can anybody tell me why cifs moved to sandbox? We moved cifs to the sandbox due to unresolved (at that time) legal issues. These issues are solved now and we will move cifs back to the head as soon as I find some time to adjust the build process as required by our rules for lgpl dependencies. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[nightly build] id failed.
Failed build logs: http://vmbuild.apache.org/~commons/nightly/logs//20070523/id.log - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Commons moving to TLP
On 5/23/07, Niall Pemberton [EMAIL PROTECTED] wrote: On 5/23/07, Dion Gillard [EMAIL PROTECTED] wrote: I think there's another issue here. Many of those who voted +1, aren't on the initial list of committers in the proposal. Also, many current commons committers aren't on the proposed list. Yup thats disappointing. Maybe not all of them follow general@ - I'm crossposting. It seems that we're not voting on that specific proposal, rather just the idea to move, and that a lot of people are being disenfranchised by not being listed. Its down to people to add themselves to the TLP resolution (they were invited to do so) - if people are disenfranchised then its their own choice. I don't know about that. It seems that a discussion and proposal taking place on a different list isn't being as inclusive as we should be. Wouldn't it be better if the initial list came from the svn acl? Would seem wrong to put people on the list without their consent. It would also seem wrong to 'remove' someone's commit access to the code by moving it to a TLP without at least keeping the dev list informed. Niall On 5/23/07, Niall Pemberton [EMAIL PROTECTED] wrote: On 5/8/07, Henri Yandell [EMAIL PROTECTED] wrote: Sadly a bit too late to make the next board meeting I suspect. However, here's a vote for Commons to officially request that it move to TLP. http://wiki.apache.org/jakarta-commons/TLPResolution Please add your name if you're a Commons developer and haven't added your name yet. [ ] +1 I support the proposal [ ] +0 I don't care [ ] -1 I'm opposed to the proposal because... Voting will close in one week. Quick summary of this thread 28 Votes for (23 binding), 4 against (3 binding). Seems to me that those objecting don't seem to have pursuaded people to change their vote. At what point do we decide on a result? Votes +1 (* indicates binding) 1. Henri Yandell(*) 2. Dennis Lundberg(*) 3. Mladen Turk(*) 4. Torsten Curdt(*) 5. Oliver Heger(*) 6. Robert Burrell Donkin(*) 7. Stephen Colebourne(*) 8. Daniel F. Savarese(*) 9. Martin Cooper(*) 10. Mark Thomas(*) 11. Niall Pemberton(*) 12. Stefan Bodewig(*) 13. Phil Steitz(*) 14. Jörg Schaible(*) 15. Jean-Frederic(*) 16. Henning Schmiedehausen(*) (conditional on The TLP proposal matching the template) 17. Nick Burch 18. Davanum Srinivas(*) 19. Thomas Vandahl 20. Oliver Zeigermann(*) 21. Rony G. Flatscher(*) 22. Scott Eade(*) 23. Yegor Kozlov 24. Luc Maisonobe 25. Mario Ivankovits(*) 26. Roland Weber(*) 27. Andrew Oliver(*) (think this was a vote for, voted -1 to Commons=Jakarta) 28. Jesse Kuhnert Added themselves to the TLP Proposal but didn't vote(?) 1. Jochen Wiedmann 2. Martin van den Bemt(*) 3. Matt Benson 4. Rory Winston(*) 5. Joerg Pietschmann Objections / Votes -1 = 1. Petar Tahchiev - sees no direct benfits for Commons 2. Ted Husted(*) - Strike Java from resolution or don't hijack Commons Name 3. Simon Kitching(*) - Will erect walls we took down - like Ted doesn't want java to monopolise commons name 4. Danny Angus(*) - preserve the Jakarta brand - Wants Jkarata==Jakarta Commons - thinks Commons should sort out Jakarta problems Bile Nonsense === Jean Carlo Salas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- dIon Gillard Rule #131 of Acquisition: Information is Profit. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VFS] Support for cifs (smb) not in VFS 1.0
Hello Mario, thanks for the fast response. Could you tell me which version of jcifs will be implemented in VFS? At the moment I think it is 0.8.3. What do you plan to use? Mit freundlichen Grüßen Detlev Mörk Systementwickler Konradin Business GmbH Ernst-Mey-Str. 8 70771 Leinfelden-Echterdingen Tel.: +49 711/7594-504 Fax.: +49 711/7594-1504 Email: [EMAIL PROTECTED] Konradin Business GmbH Sitz der Gesellschaft: Ernst-Mey-Str. 8, 70771 Leinfelden- Echterdingen Amtsgericht Stuttgart HRB 224875 Geschäftsführer: Katja Kohlhammer, Peter Dilger -Ursprüngliche Nachricht- Von: Mario Ivankovits [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 23. Mai 2007 13:36 An: Jakarta Commons Developers List Betreff: Re: [VFS] Support for cifs (smb) not in VFS 1.0 Hi! But that doesn't contain smb (cifs) anymore. Can anybody tell me why cifs moved to sandbox? We moved cifs to the sandbox due to unresolved (at that time) legal issues. These issues are solved now and we will move cifs back to the head as soon as I find some time to adjust the build process as required by our rules for lgpl dependencies. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-betwixt (in module jakarta-commons) failed
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 5 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-23052007.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: 4 mins 54 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-23052007 -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-23052007.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-23052007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-23052007.jar:/usr/local/gump/public/workspace/junit/dist/junit-23052007.jar - [junit] May 23, 2007 5:00:13 AM org.apache.commons.betwixt.versioning.VersioningStrategy checkVersionUntil [junit] INFO: value=null [junit] May 23, 2007 5:00:13 AM org.apache.commons.betwixt.versioning.VersioningStrategy checkVersionUntil [junit] INFO: version=3 [junit] May 23, 2007 5:00:13 AM org.apache.commons.betwixt.versioning.VersioningStrategy debugOptions [junit] INFO: Names: [junit] May 23, 2007 5:00:13 AM org.apache.commons.betwixt.versioning.VersioningStrategy debugOptions [junit] INFO: 0: version-from=2 [junit] May 23, 2007 5:00:13 AM org.apache.commons.betwixt.versioning.VersioningStrategy checkVersionUntil [junit] INFO: No attribute Version until [junit] May 23, 2007 5:00:13 AM org.apache.commons.betwixt.versioning.VersioningStrategy suppress [junit] INFO: Showing element [junit] May 23, 2007 5:00:13 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 23, 2007 5:00:13 AM org.apache.commons.betwixt.versioning.TestVersioning testWrite4 [junit] INFO:
[EMAIL PROTECTED]: Project commons-betwixt (in module jakarta-commons) failed
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 5 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-23052007.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: 4 mins 54 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-23052007 -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-23052007.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-23052007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-23052007.jar:/usr/local/gump/public/workspace/junit/dist/junit-23052007.jar - [junit] May 23, 2007 5:00:13 AM org.apache.commons.betwixt.versioning.VersioningStrategy checkVersionUntil [junit] INFO: value=null [junit] May 23, 2007 5:00:13 AM org.apache.commons.betwixt.versioning.VersioningStrategy checkVersionUntil [junit] INFO: version=3 [junit] May 23, 2007 5:00:13 AM org.apache.commons.betwixt.versioning.VersioningStrategy debugOptions [junit] INFO: Names: [junit] May 23, 2007 5:00:13 AM org.apache.commons.betwixt.versioning.VersioningStrategy debugOptions [junit] INFO: 0: version-from=2 [junit] May 23, 2007 5:00:13 AM org.apache.commons.betwixt.versioning.VersioningStrategy checkVersionUntil [junit] INFO: No attribute Version until [junit] May 23, 2007 5:00:13 AM org.apache.commons.betwixt.versioning.VersioningStrategy suppress [junit] INFO: Showing element [junit] May 23, 2007 5:00:13 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 23, 2007 5:00:13 AM org.apache.commons.betwixt.versioning.TestVersioning testWrite4 [junit] INFO:
[jira] Commented: (CONFIGURATION-272) ConfigurationUtils.copy results in escaped , characters no longer being escaped
[ https://issues.apache.org/jira/browse/CONFIGURATION-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498213 ] John Meagher commented on CONFIGURATION-272: With that workaround it works as expected. ConfigurationUtils.copy results in escaped , characters no longer being escaped - Key: CONFIGURATION-272 URL: https://issues.apache.org/jira/browse/CONFIGURATION-272 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.4 Environment: commons 1.4 Reporter: John Meagher Fix For: 1.5 When using ConfigurationUtils.copy to go between configuration formats any escaped out , characters are put into the output configuration without the escape character. This results in a different value being returned from getString calls as it now things the property is a list. If 4 escape characters are used instead of the expected 1 then the copy will end up with the correct value, but then the original will end up with the escape character as part of the property value. Example: SomeLongProperty=This is a test\, it is only a test # Ends up right in the copy, but not right in the original SomeOtherProperty=This is also a test, it is also only a test After copy: # Missing \ before , SomeLongProperty=This is a test, it is only a test SomeOtherProperty=This is also a test\, it is also only a test -- 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]
Re: [VFS] Support for cifs (smb) not in VFS 1.0
Hi! thanks for the fast response. Could you tell me which version of jcifs will be implemented in VFS? At the moment I think it is 0.8.3. What do you plan to use? As long as there is no compatibility break in any of the jcifs releases you can use the latest version if wanted. In our project we use jcifs 1.2.6 with VFS. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] Next release - was Re: [VOTE] 2nd attempt: Release commons-io 1.3.2
On 5/23/07, Stephen Colebourne [EMAIL PROTECTED] wrote: I would normally consider a minor point release to be essential bug fix only (in the numbering system we've been using). OK I won't port to the 1.3 branch. Perhaps, rather than trying to release 1.3.2, we should release [io] v1.4 (still JDK1.3 compatible). I'll leave that up to the RM. Niall Stephen - Original Message From: Niall Pemberton [EMAIL PROTECTED] To: Jakarta Commons Developers List commons-dev@jakarta.apache.org Sent: Tuesday, 22 May, 2007 8:51:10 PM Subject: Re: [VOTE] 2nd attempt: Release commons-io 1.3.2 I committed a small patch to the trunk today (IO-121) - since this release seems delayed is there any objections to me porting this to the 1.3 branch so it makes the 1.3.2 release? https://issues.apache.org/jira/browse/IO-121 The change is v.small - just adding a new resetByteCount() method to ThresholdingOutputStream that has 2 lines in it. Niall On 5/17/07, Jochen Wiedmann [EMAIL PROTECTED] wrote: Hi, I have fixed the issues with the file permissions and added license headers to most of the files, with the only exception of MANIFEST.MF. Now, I'd like to call for another vote on the release of commons-io 1.3.2. The proposed distributables can be found at http://people.apache.org/~jochen/commons-io/dist A KEYS file is included. The proposed site is at http://people.apache.org/~jochen/commons-io/site Thanks, Jochen [ ] +1 [ ] =0 [ ] -1 -- My cats know that I am a loser who goes out for hunting every day without ever returning as much as a single mouse. Fortunately, I've got a wife who's a real champ: She leaves the house and returns within half an hour, carrying whole bags full of meal. - 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] - 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] Created: (DBCP-225) getConnection / borrowObject fails with NullPointerException
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.2, 1.2.1 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] Commented: (CONFIGURATION-271) BaseConfiguration duplicates multi value keys values
[ https://issues.apache.org/jira/browse/CONFIGURATION-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498258 ] Daniel Adrian commented on CONFIGURATION-271: - Actually I used ConfigurationUtils. append which uses addProperty... Maybe some flag to indicate if duplicated values are allowed or not... BaseConfiguration duplicates multi value keys values Key: CONFIGURATION-271 URL: https://issues.apache.org/jira/browse/CONFIGURATION-271 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.4 Reporter: Daniel Adrian Assigned To: Emmanuel Bourg Fix For: 1.5 In addPropertyDirect(String key, Object value) the method adds the new value to the property. If the property has the same value in the list, it will get duplicated. The method should check if the list contains the value and only if the result is false add the value. There is no logic in saving a multi value key with more than one instance of a value. -- 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-jsl-test (in module commons-jelly) failed
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 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-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: 29 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-23052007.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-23052007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-23052007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-23052007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-23052007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-23052007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-23052007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-23052007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-23052007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-23052007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-23052007.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
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 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-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: 29 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-23052007.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-23052007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-23052007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-23052007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-23052007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-23052007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-23052007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-23052007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-23052007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-23052007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-23052007.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-fmt-test (in module commons-jelly) failed
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 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-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-23052007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-23052007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-23052007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/beanshell/target/commons-jelly-tags-beanshell-23052007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-23052007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-23052007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-23052007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-23052007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-23052007.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-23052007.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
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 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-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-23052007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-23052007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-23052007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/beanshell/target/commons-jelly-tags-beanshell-23052007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-23052007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-23052007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-23052007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-23052007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-23052007.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-23052007.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] Created: (CONFIGURATION-273) Saving with interpolation
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]
Re: [VFS] Support for cifs (smb) not in VFS 1.0
Mario Ivankovits wrote: Hi! thanks for the fast response. Could you tell me which version of jcifs will be implemented in VFS? At the moment I think it is 0.8.3. What do you plan to use? As long as there is no compatibility break in any of the jcifs releases you can use the latest version if wanted. In our project we use jcifs 1.2.6 with VFS. I use VFS with jcifs 1.2.13b4 and it works fine, but i've tested it just for a proof of concept deployment system. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Cordialement, Ludo - http://www.ubik-products.com --- L'amour pour principe et l'ordre pour base; le progres pour but (A.Comte) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to change/delete email header before sending it using HtmlEmail class from commons library ?
Hi, Is there any way to alter headers before sending a mail?. I looked at apis and did not find any way to do that. Seems we can add new headers but cannot replace them. I would like to hide some of the IP info from Received header. thanks, Laxman This e-mail and its attachments are confidential and solely for the intended addressee(s). Do not share or use them without Fannie Mae's approval. If received in error, contact the sender and delete them.
[jira] Created: (JXPATH-86) Children returned instead of self for arrays when using . selector
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]
Re: svn commit: r540562 - in /jakarta/commons/proper/configuration/trunk: project.xml src/java/org/apache/commons/configuration/AbstractFileConfiguration.java src/test/org/apache/commons/configuration
Emmanuel Bourg wrote: Oliver Heger a écrit : The new dependencies again cause the build under JDK 1.3 to fail because of a wrong class version. Are these additional dependencies really necessary? Okay, they are used for testing only, but maybe it would be good to keep the length of our dependency list (at least somewhat) limited. Got caught again, sorry. I'll fix that. I don't mind adding test dependencies if it improves our coverage, but it's becoming more difficult to find external libraries still working with Java 1.3 :( Emmanuel Bourg In this special case I doubt that a full blown web container is needed for achieving a good code coverage. We only have to ensure that the expected methods are called on the URLConnection. This could be done for instance with a mock URLStreamHandler implementation. Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r541074 - /jakarta/commons/proper/jci/trunk/pom.xml
Author: tcurdt Date: Wed May 23 14:05:15 2007 New Revision: 541074 URL: http://svn.apache.org/viewvc?view=revrev=541074 Log: staging repository Modified: jakarta/commons/proper/jci/trunk/pom.xml Modified: jakarta/commons/proper/jci/trunk/pom.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/jci/trunk/pom.xml?view=diffrev=541074r1=541073r2=541074 == --- jakarta/commons/proper/jci/trunk/pom.xml (original) +++ jakarta/commons/proper/jci/trunk/pom.xml Wed May 23 14:05:15 2007 @@ -31,6 +31,11 @@ moduleexamples/module /modules distributionManagement +repository +idstaging/id +nameApache Release Staging Repository/name + urlscpexe://people.apache.org/www/people.apache.org/builds/jakarta-commons/jci//url +/repository site idwebsite/id urlscpexe://people.apache.org/www/jakarta.apache.org/commons/jci//url - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r541085 - in /jakarta/commons/proper/jci/trunk: compilers/eclipse/pom.xml compilers/groovy/pom.xml compilers/janino/pom.xml compilers/javac/pom.xml compilers/rhino/pom.xml core/pom.xml exa
Author: tcurdt Date: Wed May 23 14:14:57 2007 New Revision: 541085 URL: http://svn.apache.org/viewvc?view=revrev=541085 Log: [maven-release-plugin] prepare release commons-jci-1.0 Modified: jakarta/commons/proper/jci/trunk/compilers/eclipse/pom.xml jakarta/commons/proper/jci/trunk/compilers/groovy/pom.xml jakarta/commons/proper/jci/trunk/compilers/janino/pom.xml jakarta/commons/proper/jci/trunk/compilers/javac/pom.xml jakarta/commons/proper/jci/trunk/compilers/rhino/pom.xml jakarta/commons/proper/jci/trunk/core/pom.xml jakarta/commons/proper/jci/trunk/examples/pom.xml jakarta/commons/proper/jci/trunk/fam/pom.xml jakarta/commons/proper/jci/trunk/pom.xml Modified: jakarta/commons/proper/jci/trunk/compilers/eclipse/pom.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/jci/trunk/compilers/eclipse/pom.xml?view=diffrev=541085r1=541084r2=541085 == --- jakarta/commons/proper/jci/trunk/compilers/eclipse/pom.xml (original) +++ jakarta/commons/proper/jci/trunk/compilers/eclipse/pom.xml Wed May 23 14:14:57 2007 @@ -4,11 +4,11 @@ parent groupIdorg.apache.commons/groupId artifactIdcommons-jci/artifactId -version1.0-SNAPSHOT/version +version1.0/version /parent packagingjar/packaging artifactIdcommons-jci-eclipse/artifactId -version1.0-SNAPSHOT/version +version1.0/version namecompiler-eclipse/name description Commons JCI compiler implementation for the eclipse compiler. @@ -17,7 +17,7 @@ dependency groupIdorg.apache.commons/groupId artifactIdcommons-jci-core/artifactId -version1.0-SNAPSHOT/version +version1.0/version /dependency dependency groupIdorg.apache.commons/groupId Modified: jakarta/commons/proper/jci/trunk/compilers/groovy/pom.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/jci/trunk/compilers/groovy/pom.xml?view=diffrev=541085r1=541084r2=541085 == --- jakarta/commons/proper/jci/trunk/compilers/groovy/pom.xml (original) +++ jakarta/commons/proper/jci/trunk/compilers/groovy/pom.xml Wed May 23 14:14:57 2007 @@ -4,11 +4,11 @@ parent groupIdorg.apache.commons/groupId artifactIdcommons-jci/artifactId -version1.0-SNAPSHOT/version +version1.0/version /parent packagingjar/packaging artifactIdcommons-jci-groovy/artifactId -version1.0-SNAPSHOT/version +version1.0/version namecompiler-groovy/name description Commons JCI compiler implementation for the groovy compiler. @@ -17,7 +17,7 @@ dependency groupIdorg.apache.commons/groupId artifactIdcommons-jci-core/artifactId -version1.0-SNAPSHOT/version +version1.0/version /dependency dependency groupIdorg.apache.commons/groupId Modified: jakarta/commons/proper/jci/trunk/compilers/janino/pom.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/jci/trunk/compilers/janino/pom.xml?view=diffrev=541085r1=541084r2=541085 == --- jakarta/commons/proper/jci/trunk/compilers/janino/pom.xml (original) +++ jakarta/commons/proper/jci/trunk/compilers/janino/pom.xml Wed May 23 14:14:57 2007 @@ -4,11 +4,11 @@ parent groupIdorg.apache.commons/groupId artifactIdcommons-jci/artifactId -version1.0-SNAPSHOT/version +version1.0/version /parent packagingjar/packaging artifactIdcommons-jci-janino/artifactId -version1.0-SNAPSHOT/version +version1.0/version namecompiler-janino/name description Commons JCI compiler implementation for the janino compiler. @@ -17,7 +17,7 @@ dependency groupIdorg.apache.commons/groupId artifactIdcommons-jci-core/artifactId -version1.0-SNAPSHOT/version +version1.0/version /dependency dependency groupIdorg.apache.commons/groupId Modified: jakarta/commons/proper/jci/trunk/compilers/javac/pom.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/jci/trunk/compilers/javac/pom.xml?view=diffrev=541085r1=541084r2=541085 == --- jakarta/commons/proper/jci/trunk/compilers/javac/pom.xml (original) +++ jakarta/commons/proper/jci/trunk/compilers/javac/pom.xml Wed May 23 14:14:57 2007 @@ -4,11 +4,11 @@ parent groupIdorg.apache.commons/groupId artifactIdcommons-jci/artifactId -version1.0-SNAPSHOT/version +version1.0/version /parent packagingjar/packaging artifactIdcommons-jci-javac/artifactId -version1.0-SNAPSHOT/version +version1.0/version
svn commit: r541086 - in /jakarta/commons/proper/jci/tags/commons-jci-1.0: ./ compilers/eclipse/ compilers/groovy/ compilers/janino/ compilers/javac/ compilers/rhino/ core/ core/src/main/java/org/apac
Author: tcurdt Date: Wed May 23 14:15:20 2007 New Revision: 541086 URL: http://svn.apache.org/viewvc?view=revrev=541086 Log: [maven-scm] copy for tag commons-jci-1.0 Added: jakarta/commons/proper/jci/tags/commons-jci-1.0/ - copied from r538079, jakarta/commons/proper/jci/trunk/ jakarta/commons/proper/jci/tags/commons-jci-1.0/compilers/eclipse/pom.xml - copied unchanged from r541085, jakarta/commons/proper/jci/trunk/compilers/eclipse/pom.xml jakarta/commons/proper/jci/tags/commons-jci-1.0/compilers/groovy/pom.xml - copied unchanged from r541085, jakarta/commons/proper/jci/trunk/compilers/groovy/pom.xml jakarta/commons/proper/jci/tags/commons-jci-1.0/compilers/janino/pom.xml - copied unchanged from r541085, jakarta/commons/proper/jci/trunk/compilers/janino/pom.xml jakarta/commons/proper/jci/tags/commons-jci-1.0/compilers/javac/pom.xml - copied unchanged from r541085, jakarta/commons/proper/jci/trunk/compilers/javac/pom.xml jakarta/commons/proper/jci/tags/commons-jci-1.0/compilers/rhino/pom.xml - copied unchanged from r541085, jakarta/commons/proper/jci/trunk/compilers/rhino/pom.xml jakarta/commons/proper/jci/tags/commons-jci-1.0/core/pom.xml - copied unchanged from r541085, jakarta/commons/proper/jci/trunk/core/pom.xml jakarta/commons/proper/jci/tags/commons-jci-1.0/core/src/main/java/org/apache/commons/jci/ReloadingClassLoader.java - copied unchanged from r538753, jakarta/commons/proper/jci/trunk/core/src/main/java/org/apache/commons/jci/ReloadingClassLoader.java jakarta/commons/proper/jci/tags/commons-jci-1.0/core/src/main/java/org/apache/commons/jci/utils/ConversionUtils.java - copied unchanged from r538753, jakarta/commons/proper/jci/trunk/core/src/main/java/org/apache/commons/jci/utils/ConversionUtils.java jakarta/commons/proper/jci/tags/commons-jci-1.0/core/src/test/java/org/apache/commons/jci/ReloadingClassLoaderRemoveTestCase.java - copied unchanged from r538753, jakarta/commons/proper/jci/trunk/core/src/test/java/org/apache/commons/jci/ReloadingClassLoaderRemoveTestCase.java jakarta/commons/proper/jci/tags/commons-jci-1.0/examples/pom.xml - copied unchanged from r541085, jakarta/commons/proper/jci/trunk/examples/pom.xml jakarta/commons/proper/jci/tags/commons-jci-1.0/fam/pom.xml - copied unchanged from r541085, jakarta/commons/proper/jci/trunk/fam/pom.xml jakarta/commons/proper/jci/tags/commons-jci-1.0/pom.xml - copied unchanged from r541085, jakarta/commons/proper/jci/trunk/pom.xml - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r541087 - in /jakarta/commons/proper/jci/trunk: compilers/eclipse/pom.xml compilers/groovy/pom.xml compilers/janino/pom.xml compilers/javac/pom.xml compilers/rhino/pom.xml core/pom.xml exa
Author: tcurdt Date: Wed May 23 14:15:32 2007 New Revision: 541087 URL: http://svn.apache.org/viewvc?view=revrev=541087 Log: [maven-release-plugin] prepare for next development iteration Modified: jakarta/commons/proper/jci/trunk/compilers/eclipse/pom.xml jakarta/commons/proper/jci/trunk/compilers/groovy/pom.xml jakarta/commons/proper/jci/trunk/compilers/janino/pom.xml jakarta/commons/proper/jci/trunk/compilers/javac/pom.xml jakarta/commons/proper/jci/trunk/compilers/rhino/pom.xml jakarta/commons/proper/jci/trunk/core/pom.xml jakarta/commons/proper/jci/trunk/examples/pom.xml jakarta/commons/proper/jci/trunk/fam/pom.xml jakarta/commons/proper/jci/trunk/pom.xml Modified: jakarta/commons/proper/jci/trunk/compilers/eclipse/pom.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/jci/trunk/compilers/eclipse/pom.xml?view=diffrev=541087r1=541086r2=541087 == --- jakarta/commons/proper/jci/trunk/compilers/eclipse/pom.xml (original) +++ jakarta/commons/proper/jci/trunk/compilers/eclipse/pom.xml Wed May 23 14:15:32 2007 @@ -4,11 +4,11 @@ parent groupIdorg.apache.commons/groupId artifactIdcommons-jci/artifactId -version1.0/version +version1.1-SNAPSHOT/version /parent packagingjar/packaging artifactIdcommons-jci-eclipse/artifactId -version1.0/version +version1.1-SNAPSHOT/version namecompiler-eclipse/name description Commons JCI compiler implementation for the eclipse compiler. Modified: jakarta/commons/proper/jci/trunk/compilers/groovy/pom.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/jci/trunk/compilers/groovy/pom.xml?view=diffrev=541087r1=541086r2=541087 == --- jakarta/commons/proper/jci/trunk/compilers/groovy/pom.xml (original) +++ jakarta/commons/proper/jci/trunk/compilers/groovy/pom.xml Wed May 23 14:15:32 2007 @@ -4,11 +4,11 @@ parent groupIdorg.apache.commons/groupId artifactIdcommons-jci/artifactId -version1.0/version +version1.1-SNAPSHOT/version /parent packagingjar/packaging artifactIdcommons-jci-groovy/artifactId -version1.0/version +version1.1-SNAPSHOT/version namecompiler-groovy/name description Commons JCI compiler implementation for the groovy compiler. Modified: jakarta/commons/proper/jci/trunk/compilers/janino/pom.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/jci/trunk/compilers/janino/pom.xml?view=diffrev=541087r1=541086r2=541087 == --- jakarta/commons/proper/jci/trunk/compilers/janino/pom.xml (original) +++ jakarta/commons/proper/jci/trunk/compilers/janino/pom.xml Wed May 23 14:15:32 2007 @@ -4,11 +4,11 @@ parent groupIdorg.apache.commons/groupId artifactIdcommons-jci/artifactId -version1.0/version +version1.1-SNAPSHOT/version /parent packagingjar/packaging artifactIdcommons-jci-janino/artifactId -version1.0/version +version1.1-SNAPSHOT/version namecompiler-janino/name description Commons JCI compiler implementation for the janino compiler. Modified: jakarta/commons/proper/jci/trunk/compilers/javac/pom.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/jci/trunk/compilers/javac/pom.xml?view=diffrev=541087r1=541086r2=541087 == --- jakarta/commons/proper/jci/trunk/compilers/javac/pom.xml (original) +++ jakarta/commons/proper/jci/trunk/compilers/javac/pom.xml Wed May 23 14:15:32 2007 @@ -4,11 +4,11 @@ parent groupIdorg.apache.commons/groupId artifactIdcommons-jci/artifactId -version1.0/version +version1.1-SNAPSHOT/version /parent packagingjar/packaging artifactIdcommons-jci-javac/artifactId -version1.0/version +version1.1-SNAPSHOT/version namecompiler-javac/name description Commons JCI compiler implementation for the javac compiler (up to JDK 1.5). Modified: jakarta/commons/proper/jci/trunk/compilers/rhino/pom.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/jci/trunk/compilers/rhino/pom.xml?view=diffrev=541087r1=541086r2=541087 == --- jakarta/commons/proper/jci/trunk/compilers/rhino/pom.xml (original) +++ jakarta/commons/proper/jci/trunk/compilers/rhino/pom.xml Wed May 23 14:15:32 2007 @@ -4,11 +4,11 @@ parent groupIdorg.apache.commons/groupId artifactIdcommons-jci/artifactId -version1.0/version +version1.1-SNAPSHOT/version /parent packagingjar/packaging artifactIdcommons-jci-rhino/artifactId -version1.0/version +
svn commit: r541094 - in /jakarta/commons/proper/jci/tags: 1.0-RC2/ commons-jci-1.0/
Author: tcurdt Date: Wed May 23 14:29:01 2007 New Revision: 541094 URL: http://svn.apache.org/viewvc?view=revrev=541094 Log: RC2 Added: jakarta/commons/proper/jci/tags/1.0-RC2/ - copied from r541093, jakarta/commons/proper/jci/tags/commons-jci-1.0/ Removed: jakarta/commons/proper/jci/tags/commons-jci-1.0/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r541100 - /jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/converters/NumberConverter.java
Author: niallp
Date: Wed May 23 15:11:28 2007
New Revision: 541100
URL: http://svn.apache.org/viewvc?view=revrev=541100
Log:
Improve BigInteger / BigDecimal conversion handling
Modified:
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/converters/NumberConverter.java
Modified:
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/converters/NumberConverter.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/converters/NumberConverter.java?view=diffrev=541100r1=541099r2=541100
==
---
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/converters/NumberConverter.java
(original)
+++
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/converters/NumberConverter.java
Wed May 23 15:11:28 2007
@@ -363,6 +363,8 @@
if (type.equals(BigDecimal.class)) {
if (value instanceof Float || value instanceof Double) {
return new BigDecimal(value.toString());
+} else if (value instanceof BigInteger) {
+return new BigDecimal((BigInteger)value);
} else {
return BigDecimal.valueOf(value.longValue());
}
@@ -370,7 +372,11 @@
// BigInteger
if (type.equals(BigInteger.class)) {
-return BigInteger.valueOf(value.longValue());
+if (value instanceof BigDecimal) {
+return ((BigDecimal)value).toBigInteger();
+} else {
+return BigInteger.valueOf(value.longValue());
+}
}
String msg = toString(getClass()) + cannot handle conversion to '
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (NET-148) Relaxed condition in __getReply causes other failures.
[
https://issues.apache.org/jira/browse/NET-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498429
]
Rory Winston commented on NET-148:
--
Thanks Matthew , that is very helpful. I can reproduce the issue now. I think
we may need to modify that condition to fix this.
Relaxed condition in __getReply causes other failures.
--
Key: NET-148
URL: https://issues.apache.org/jira/browse/NET-148
Project: Commons Net
Issue Type: Bug
Affects Versions: 1.4, Nightly Builds
Reporter: Matthew Simoneau
Assigned To: Rory Winston
In FTP.java's __getReply() method, this do/while loop reads multi-line
responses from the server:
do
{
line = _controlInput.readLine();
...
}
while (!(line.length() = 4 line.charAt(3) != '-'
Character.isDigit(line.charAt(0;
// This is too strong a condition because of non-conforming ftp
// servers like ftp.funet.fi which sent 226 as the last line of a
// 426 multi-line reply in response to ls /. We relax the
condition to
// test that the line starts with a digit rather than starting
with
// the code.
// line.startsWith(code)));
}
Note the comment and the commented-out termination condition. I think the
relevant spec is http://www.ietf.org/rfc/rfc0959.txt and the section is
4.2. FTP REPLIES. This is causing problems with the return from the STAT
command from Geocities' FTP servers. Here is an example reply.
211- ftp.us.geocities.com FTP server status:
Version wu-2.6.0(48) Tue Jan 2 16:30:15 PST 2007
Connected to 144.212.217.85
Logged in anonymously
TYPE: ASCII, FORM: Nonprint; STRUcture: File; transfer MODE: Stream
No data connection
0 data bytes received in 0 files
0 data bytes transmitted in 0 files
0 data bytes total in 0 files
57 traffic bytes received in 0 transfers
733 traffic bytes transmitted in 0 transfers
834 traffic bytes total in 0 transfers
211 End of status
Note that the line 0 data bytes total in 0 files starts with a digit, but
it isn't a reply code. This prematurely halts reading of lines from the
server, and the remaining lines will look like a reply from the next command.
--
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: (NET-148) Relaxed condition in __getReply causes other failures.
[
https://issues.apache.org/jira/browse/NET-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rory Winston updated NET-148:
-
Fix Version/s: 2.0
Relaxed condition in __getReply causes other failures.
--
Key: NET-148
URL: https://issues.apache.org/jira/browse/NET-148
Project: Commons Net
Issue Type: Bug
Affects Versions: 1.4, Nightly Builds
Reporter: Matthew Simoneau
Assigned To: Rory Winston
Fix For: 2.0
In FTP.java's __getReply() method, this do/while loop reads multi-line
responses from the server:
do
{
line = _controlInput.readLine();
...
}
while (!(line.length() = 4 line.charAt(3) != '-'
Character.isDigit(line.charAt(0;
// This is too strong a condition because of non-conforming ftp
// servers like ftp.funet.fi which sent 226 as the last line of a
// 426 multi-line reply in response to ls /. We relax the
condition to
// test that the line starts with a digit rather than starting
with
// the code.
// line.startsWith(code)));
}
Note the comment and the commented-out termination condition. I think the
relevant spec is http://www.ietf.org/rfc/rfc0959.txt and the section is
4.2. FTP REPLIES. This is causing problems with the return from the STAT
command from Geocities' FTP servers. Here is an example reply.
211- ftp.us.geocities.com FTP server status:
Version wu-2.6.0(48) Tue Jan 2 16:30:15 PST 2007
Connected to 144.212.217.85
Logged in anonymously
TYPE: ASCII, FORM: Nonprint; STRUcture: File; transfer MODE: Stream
No data connection
0 data bytes received in 0 files
0 data bytes transmitted in 0 files
0 data bytes total in 0 files
57 traffic bytes received in 0 transfers
733 traffic bytes transmitted in 0 transfers
834 traffic bytes total in 0 transfers
211 End of status
Note that the line 0 data bytes total in 0 files starts with a digit, but
it isn't a reply code. This prematurely halts reading of lines from the
server, and the remaining lines will look like a reply from the next command.
--
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: r541122 - in /jakarta/commons/proper/beanutils/trunk/src: java/org/apache/commons/beanutils/converters/ test/org/apache/commons/beanutils/converters/
Author: niallp
Date: Wed May 23 17:18:01 2007
New Revision: 541122
URL: http://svn.apache.org/viewvc?view=revrev=541122
Log:
Improve exception error messages and add Calendar -- Long conversion
Modified:
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/converters/AbstractConverter.java
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/converters/DateTimeConverter.java
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/converters/NumberConverter.java
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/converters/NumberConverterTestBase.java
Modified:
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/converters/AbstractConverter.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/converters/AbstractConverter.java?view=diffrev=541122r1=541121r2=541122
==
---
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/converters/AbstractConverter.java
(original)
+++
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/converters/AbstractConverter.java
Wed May 23 17:18:01 2007
@@ -404,7 +404,9 @@
} else {
typeName = type.getName();
}
-if (typeName.startsWith(java.lang.)) {
+if (typeName.startsWith(java.lang.) ||
+typeName.startsWith(java.util.) ||
+typeName.startsWith(java.math.)) {
typeName = typeName.substring(java.lang..length());
} else if (typeName.startsWith(PACKAGE)) {
typeName = typeName.substring(PACKAGE.length());
Modified:
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/converters/DateTimeConverter.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/converters/DateTimeConverter.java?view=diffrev=541122r1=541121r2=541122
==
---
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/converters/DateTimeConverter.java
(original)
+++
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/converters/DateTimeConverter.java
Wed May 23 17:18:01 2007
@@ -281,12 +281,14 @@
* Otherwise the default codeDateFormat/code for the default locale
* (and istyle/i if configured) will be used.
*
- * @param type Data type to which this value should be converted.
+ * @param targetType Data type to which this value should be converted.
* @param value The input value to be converted.
* @return The converted value.
* @throws Exception if conversion cannot be performed successfully
*/
-protected Object convertToType(Class type, Object value) throws Exception {
+protected Object convertToType(Class targetType, Object value) throws
Exception {
+
+Class sourceType = value.getClass();
// Handle java.sql.Timestamp
if (value instanceof java.sql.Timestamp) {
@@ -299,51 +301,51 @@
long timeInMillis = ((timestamp.getTime() / 1000) * 1000);
timeInMillis += timestamp.getNanos() / 100;
// -- JDK 1.3 Fix --
-return toDate(type, timeInMillis);
+return toDate(targetType, timeInMillis);
}
// Handle Date (includes java.sql.Date java.sql.Time)
if (value instanceof Date) {
Date date = (Date)value;
-return toDate(type, date.getTime());
+return toDate(targetType, date.getTime());
}
// Handle Calendar
if (value instanceof Calendar) {
Calendar calendar = (Calendar)value;
-return toDate(type, calendar.getTime().getTime());
+return toDate(targetType, calendar.getTime().getTime());
}
// Handle Long
if (value instanceof Long) {
Long longObj = (Long)value;
-return toDate(type, longObj.longValue());
+return toDate(targetType, longObj.longValue());
}
// Convert all other types to String handle
String stringValue = value.toString().trim();
if (stringValue.length() == 0) {
-return handleMissing(type);
+return handleMissing(targetType);
}
// Parse the Date/Time
if (useLocaleFormat) {
Calendar calendar = null;
if (patterns != null patterns.length 0) {
-calendar = parse(type, stringValue);
+calendar = parse(sourceType, targetType, stringValue);
} else {
DateFormat format = getFormat(locale, timeZone);
-calendar = parse(type,
[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: BugCLI71Test.java
Adding a new test case with the new tests in them.
[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, 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_12498436
]
Henri Yandell commented on CLI-71:
--
So... in terms of problems we have the following test cases:
1] -a Caesar -k a does not work. I think that should be fixed and it's in
the attached unit test. It's a bit more convoluted than Amro noticed, it only
fails when the parser has been setup the first time with a different structure.
Something it lingering in the parser.
2] -k -a Caesar does not error. I think it should. Need to add that to the
test.
3] -k -a Caesar where k is optional has k as being not set rather than
having a default. Need to add to the unit test.
[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, 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: (was: BugCLI71Test.java)
[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, 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: BugCLI71Test.java
[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, 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_12498440
]
Henri Yandell commented on CLI-71:
--
1] fails. As I said, something is lingering.
2] passes. An error is created, so things have changed since the version Amro
was using.
3] passes. If you use the default value API, you get the default value back.
[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, 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_12498441
]
Henri Yandell commented on CLI-71:
--
Testing by changing the test to use a fresh options object and then a fresh
parser object, the Options class is the one with the issue.
It wraps Option and OptionGroup classes. Looking at the PosixParser superclass
Parser, the problem would seem to be:
opt.addValue( Util.stripLeadingAndTrailingQuotes(str) );
ie) It's changing one of the Option classes; which is then handed over to the
CommandLine object.
A simple solution would be to clone the Option before passing it along to
modify it. This could be done in Options.getValue, but I'm wary of putting it
there. Simpler to put in the Parser class for just that usage of
Options.getValue. My first stab at this breaks other tests.
[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:
[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-badfix.patch
Attaching my first (test breaking) fix patch. Stopping working on this for the
moment, so if anyone wants to feel free to jump in.
[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]
Functor Users / Project Management?
Hi all, I'm not really sure how this is done but over the past year and a half or so, I've been working one of the original functor contributors, Jason Horman, on a branch of functor and we've made a lot of progress with it. For example, it's updated to take advantage of generics which is extremely helpful and also have done a lot work developing compilers that allows you to translate expressions into runtime functions, etc. This has been extremely useful for us on our project and we'd like to get this code back into the main branch. I've emailed Rodney Waldhoff, who is listed as the project lead for functor but haven't heard back. There's been no progress on functor since 2005 and I don't want to step on toes, but I'm also interested in contributing to the community. Any pointers on what can be done would be appreciated. Thanks, Pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (FILEUPLOAD-135) InputStream created with Streaming API returns EOF on first read() for short files uploaded from FireFox over HTTPS
InputStream created with Streaming API returns EOF on first read() for short files uploaded from FireFox over HTTPS --- Key: FILEUPLOAD-135 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-135 Project: Commons FileUpload Issue Type: Bug Affects Versions: 1.2, 1.2.1 Environment: Windows XP Browser: Firefox 1.5.0.11 Protocol: HTTPS Reporter: Alexander Sova I was able to reproduce this problem happens only with files shorer then boundary string generated by browser and only with Firefox using HTTPS protocol. For some reason in this particular environment inputStream.read() in MultipartStream.ItemInputStream.makeAvailable() reads not whole HTTP response body, but only file content before boundary string. I've created a patch fixing this issue. -- 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: (FILEUPLOAD-135) InputStream created with Streaming API returns EOF on first read() for short files uploaded from FireFox over HTTPS
[ https://issues.apache.org/jira/browse/FILEUPLOAD-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Sova updated FILEUPLOAD-135: -- Attachment: commons-fileupload-1.1-bug-short-file-eof.patch reading from inputStream until we get enough content to fit boundary string InputStream created with Streaming API returns EOF on first read() for short files uploaded from FireFox over HTTPS --- Key: FILEUPLOAD-135 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-135 Project: Commons FileUpload Issue Type: Bug Affects Versions: 1.2, 1.2.1 Environment: Windows XP Browser: Firefox 1.5.0.11 Protocol: HTTPS Reporter: Alexander Sova Attachments: commons-fileupload-1.1-bug-short-file-eof.patch I was able to reproduce this problem happens only with files shorer then boundary string generated by browser and only with Firefox using HTTPS protocol. For some reason in this particular environment inputStream.read() in MultipartStream.ItemInputStream.makeAvailable() reads not whole HTTP response body, but only file content before boundary string. I've created a patch fixing this issue. -- 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
[
https://issues.apache.org/jira/browse/JXPATH-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498479
]
Matt Benson commented on JXPATH-86:
---
Some of this report is probably valid, but I remain skeptical on some things.
Your complaints about *, for example, are invalid because JXPath, by design,
returns only the first matching value from getValue() and getPointer(). You
should find that e.g. iterate(), iteratePointers(), and/or selectNodes() would
work for you here. The only correctly incorrect thing I see in this bugrep
is:
/array/. - /[EMAIL PROTECTED]'array'][1]
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]
