[ANNOUNCEMENT] release of common jci 1.0
Jakarta Commons JCI 1.0 is now available! http://jakarta.apache.org/commons/jci/ JCI is a java compiler interface. It can be used to either compile java (or any other language that can be compiled to java classes like e.g. groovy or javascript) to java. It is well integrated with a FAM (FilesystemAlterationMonitor) that can be used with the JCI compiling/ reloading classloader. All the currently supported compilers (even javac before java6) feature in-memory compilation. It currently supports compilers like eclipse, janino, groovy, rhino and javac. Apache Jakarta Commons JCI is available in either binary or source form from the JCI downloads page or your favorite maven repository mirror. http://jakarta.apache.org/site/downloads/downloads_commons-jci.cgi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (LANG-340) performance problem with EqualsBuilder.append()
performance problem with EqualsBuilder.append()
---
Key: LANG-340
URL: https://issues.apache.org/jira/browse/LANG-340
Project: Commons Lang
Issue Type: Improvement
Affects Versions: 2.3
Reporter: Ramil Israfilov
We are using EqualsBuilder for construction of equals() method in our javabeans.
For example we have a class:
public class SimpleRecord{
String name;
String label;
...
public boolean equals(Object object) {
return new EqualsBuilder().append(this.label, rhs.label).append(
this.getName(), rhs.getName()).isEquals();
}
So far so good.
But one of our applications uses extensively Stack to push/pop SimpleRecord
bean. And it was working very slow.
After profiling of application we saw that most of the time JVM spent in
equals() method of SimpleRecord. (it is called during peek() which is calling
remove() from Stack)
If we replace EqualsBuilder by following code our application worked 3 times
faster ! Could you make some optimizations ?
if (!(object instanceof SimpleRecord)) {
return false;
}
SimpleRecord rhs = (SimpleRecord) object;
if (this.getName() == null rhs.getName() != null) {
return false;
} else
if (rhs.getName() == null this.getName() != null) {
return false;
} else
if (this.label == null rhs.label != null) {
return false;
} else
if (rhs.label == null this.label != null) {
return false;
} else
if (this.label == null rhs.label == null) {
return this.getName().equals(rhs.getName());
} else
return this.getName().equals(rhs.getName())
this.label.equals(rhs.label);
--
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: [RESULT] 3rd attempt: Release commons-io 1.3.2
I requested one of two remedies: a) Release as 1.3.2, but undeprecate the static utility class FileCleaner methods (they would be deprecated in 1.4). The static methods can have comments added in 1.3.2 indicating the preferred alternative. b) Release as 1.4. I also have no recollection of a release with an unresolved -1. I would strongly prefer one of the two remedies to be applied. I also agree that we desperately need this to be properly agreed and documented. Stephen - Original Message From: Ben Speakmon [EMAIL PROTECTED] To: Jakarta Commons Developers List commons-dev@jakarta.apache.org Sent: Wednesday, 20 June, 2007 5:42:32 AM Subject: Re: [RESULT] 3rd attempt: Release commons-io 1.3.2 Is there anything at stake beyond the version number? If it's called 1.4instead of 1.3.2, does that fully answer the concern? On 6/19/07, Phil Steitz [EMAIL PROTECTED] wrote: On 6/19/07, Dion Gillard [EMAIL PROTECTED] wrote: I believe you're right. http://jakarta.apache.org/site/proposal.html#decisions/items/plan says ...Majority approval is required before the public release can be made. Yes, that is the policy, but I have never seen us move forward with a release with an unresolved -1 in commons. Could be this has happened, but not in the last 4 or so years. It is up to the RM, but with a -1 from a major contributor to the code base, I would personally not push out the release. FWIW, as mentioned on other threads, I agree with Stephen on the version number issue. Phil - 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]
Re: [all] Versioining and compatibility WAS Re: [VOTE] Release CLI 1.1
Rahul Akolkar rahul.akolkar at gmail.com writes: We still do: http://jakarta.apache.org/commons/releases/versioning.html Regarding deprecation: It is considered a fully compatible change. So you can actually deprecate at any point and don't need to postpone it a next release of a particular type. Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[vfs] HttpClient 3.x Compatibility?
Help! I'm in jar hell (again). Apparently, HttpClient v2.0.2 and 3.0.1(current stable release) are not binary compatible. They introduced setParams()/getParams() methods into the HttpConnectionManager interface. However, VFS' WebdavConnectionManager doesn't implement these methods and it can't unless it upgrades its dependency to HttpClient 3.0.1, since the property type of the params property isn't introduced until 3.0.1. This causes a major issue, because my project requires the 3.0.1 version of HttpClient, but we're also using VFS' webdav support, so we're required to stick with HttpClient 2.0.2 to resolve this issue. Any suggestions?
[EMAIL PROTECTED]: Project commons-email (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-email has an issue affecting its community integration. This issue affects 2 projects, and has been outstanding for 25 runs. The current state of this project is 'Failed', with reason 'Missing Build Outputs'. For reference only, the following projects are affected by this: - commons-email : Commons Email Package - fulcrum-template : Services Framework Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons/commons-email/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-email-20062007.jar] identifier set to project name -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/jakarta-commons/email/profiles.xml -DEBUG- Maven POM in: /usr/local/gump/public/workspace/jakarta-commons/email/pom.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/jakarta-commons/email/project.properties -INFO- Failed with reason missing build outputs -ERROR- Missing Output: /usr/local/gump/public/workspace/jakarta-commons/email/target/commons-email-20062007.jar -ERROR- See Directory Listing Work for Missing Outputs -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons/commons-email/gump_work/build_jakarta-commons_commons-email.html Work Name: build_jakarta-commons_commons-email (Type: Build) Work ended in a state of : Success Elapsed: 31 secs Command Line: mvn package [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/email] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/target/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/jakarta-commons/lang/commons-lang-20062007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/usr/local/gump/public/workspace/jakarta-commons/email/lib/subethasmtp-smtp-1.2-java14.jar:/usr/local/gump/public/workspace/jakarta-commons/email/lib/subethasmtp-wiser-1.2-java14.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-20062007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-20062007.jar:/usr/local/gump/packages/maven-findbugs-plugin/maven-findbugs-plugin-0.9.1.jar:/usr/local/gump/packages/maven-cobertura-plugin/maven-cobertura-plugin-1.1.jar:/usr/local/gump/packages/jaf-1.1ea/activation.jar:/usr/local/gump/packages/javamail-1.4/mail.jar - Downloading: http://repo1.maven.org/maven2/jaxen/jaxen/1.0-FCS/jaxen-1.0-FCS.jar 2/187K 5/187K 7/187K 8/187K 11/187K 15/187K 19/187K 23/187K 27/187K 28/187K 29/187K 33/187K 37/187K 41/187K 45/187K 49/187K 53/187K 57/187K 60/187K 62/187K 66/187K 70/187K 74/187K 78/187K 82/187K 86/187K 90/187K 94/187K 98/187K 101/187K 105/187K 109/187K 113/187K 117/187K 121/187K 125/187K 129/187K 133/187K 137/187K 141/187K 145/187K 148/187K 152/187K 156/187K 160/187K 164/187K 168/187K 172/187K 176/187K 180/187K 184/187K 185/187K 187/187K 187K downloaded Downloading: http://repo1.maven.org/maven2/saxpath/saxpath/1.0-FCS/saxpath-1.0-FCS.jar 1/23K 2/23K 4/23K 5/23K 9/23K 11/23K 15/23K 19/23K 23/23K 23K downloaded Downloading: http://repo1.maven.org/maven2/msv/msv/20020414/msv-20020414.jar 2/1133K 5/1133K 7/1133K 11/1133K 11/1133K 15/1133K 15/1133K 16/1133K 20/1133K 24/1133K 26/1133K 30/1133K 34/1133K 38/1133K 42/1133K 46/1133K 49/1133K 53/1133K 57/1133K 61/1133K 65/1133K 69/1133K 73/1133K 77/1133K 81/1133K 85/1133K 86/1133K 90/1133K 94/1133K 98/1133K 102/1133K 106/1133K 110/1133K 114/1133K 118/1133K 122/1133K 126/1133K 128/1133K 132/1133K 136/1133K 140/1133K 144/1133K 148/1133K 152/1133K 156/1133K 160/1133K 164/1133K 168/1133K 172/1133K 176/1133K 180/1133K 181/1133K 185/1133K 189/1133K 193/1133K 197/1133K 197/1133K 200/1133K 202/1133K 206/1133K 210/1133K 214/1133K 218/1133K 222/1133K 226/1133K 230/1133K 234/1133K 234/1133K 237/1133K 241/1133K 245/1133K 249/1133K 253/1133K 257/1133K 261/1133K 263/1133K 267/1133K 271/1133K 275/1133K 279/1133K
[EMAIL PROTECTED]: Project commons-email (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-email has an issue affecting its community integration. This issue affects 2 projects, and has been outstanding for 25 runs. The current state of this project is 'Failed', with reason 'Missing Build Outputs'. For reference only, the following projects are affected by this: - commons-email : Commons Email Package - fulcrum-template : Services Framework Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons/commons-email/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-email-20062007.jar] identifier set to project name -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/jakarta-commons/email/profiles.xml -DEBUG- Maven POM in: /usr/local/gump/public/workspace/jakarta-commons/email/pom.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/jakarta-commons/email/project.properties -INFO- Failed with reason missing build outputs -ERROR- Missing Output: /usr/local/gump/public/workspace/jakarta-commons/email/target/commons-email-20062007.jar -ERROR- See Directory Listing Work for Missing Outputs -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons/commons-email/gump_work/build_jakarta-commons_commons-email.html Work Name: build_jakarta-commons_commons-email (Type: Build) Work ended in a state of : Success Elapsed: 31 secs Command Line: mvn package [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/email] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/target/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/jakarta-commons/lang/commons-lang-20062007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/usr/local/gump/public/workspace/jakarta-commons/email/lib/subethasmtp-smtp-1.2-java14.jar:/usr/local/gump/public/workspace/jakarta-commons/email/lib/subethasmtp-wiser-1.2-java14.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-20062007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-20062007.jar:/usr/local/gump/packages/maven-findbugs-plugin/maven-findbugs-plugin-0.9.1.jar:/usr/local/gump/packages/maven-cobertura-plugin/maven-cobertura-plugin-1.1.jar:/usr/local/gump/packages/jaf-1.1ea/activation.jar:/usr/local/gump/packages/javamail-1.4/mail.jar - Downloading: http://repo1.maven.org/maven2/jaxen/jaxen/1.0-FCS/jaxen-1.0-FCS.jar 2/187K 5/187K 7/187K 8/187K 11/187K 15/187K 19/187K 23/187K 27/187K 28/187K 29/187K 33/187K 37/187K 41/187K 45/187K 49/187K 53/187K 57/187K 60/187K 62/187K 66/187K 70/187K 74/187K 78/187K 82/187K 86/187K 90/187K 94/187K 98/187K 101/187K 105/187K 109/187K 113/187K 117/187K 121/187K 125/187K 129/187K 133/187K 137/187K 141/187K 145/187K 148/187K 152/187K 156/187K 160/187K 164/187K 168/187K 172/187K 176/187K 180/187K 184/187K 185/187K 187/187K 187K downloaded Downloading: http://repo1.maven.org/maven2/saxpath/saxpath/1.0-FCS/saxpath-1.0-FCS.jar 1/23K 2/23K 4/23K 5/23K 9/23K 11/23K 15/23K 19/23K 23/23K 23K downloaded Downloading: http://repo1.maven.org/maven2/msv/msv/20020414/msv-20020414.jar 2/1133K 5/1133K 7/1133K 11/1133K 11/1133K 15/1133K 15/1133K 16/1133K 20/1133K 24/1133K 26/1133K 30/1133K 34/1133K 38/1133K 42/1133K 46/1133K 49/1133K 53/1133K 57/1133K 61/1133K 65/1133K 69/1133K 73/1133K 77/1133K 81/1133K 85/1133K 86/1133K 90/1133K 94/1133K 98/1133K 102/1133K 106/1133K 110/1133K 114/1133K 118/1133K 122/1133K 126/1133K 128/1133K 132/1133K 136/1133K 140/1133K 144/1133K 148/1133K 152/1133K 156/1133K 160/1133K 164/1133K 168/1133K 172/1133K 176/1133K 180/1133K 181/1133K 185/1133K 189/1133K 193/1133K 197/1133K 197/1133K 200/1133K 202/1133K 206/1133K 210/1133K 214/1133K 218/1133K 222/1133K 226/1133K 230/1133K 234/1133K 234/1133K 237/1133K 241/1133K 245/1133K 249/1133K 253/1133K 257/1133K 261/1133K 263/1133K 267/1133K 271/1133K 275/1133K 279/1133K
[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 7 projects, and has been outstanding for 50 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 - 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-20062007.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: 2 mins 40 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-20062007 -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-20062007.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-20062007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-20062007.jar:/usr/local/gump/public/workspace/junit/dist/junit-20062007.jar - [junit] Jun 20, 2007 6:14:58 AM org.apache.commons.betwixt.versioning.VersioningStrategy checkVersionUntil [junit] INFO: value=null [junit] Jun 20, 2007 6:14:58 AM org.apache.commons.betwixt.versioning.VersioningStrategy checkVersionUntil [junit] INFO: version=3 [junit] Jun 20, 2007 6:14:58 AM org.apache.commons.betwixt.versioning.VersioningStrategy debugOptions [junit] INFO: Names: [junit] Jun 20, 2007 6:14:58 AM org.apache.commons.betwixt.versioning.VersioningStrategy debugOptions [junit] INFO: 0: version-from=2 [junit] Jun 20, 2007 6:14:58 AM org.apache.commons.betwixt.versioning.VersioningStrategy checkVersionUntil [junit] INFO: No attribute Version until [junit] Jun 20, 2007 6:14:58 AM org.apache.commons.betwixt.versioning.VersioningStrategy suppress [junit] INFO: Showing element [junit] Jun 20, 2007 6:14:58 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] Jun 20, 2007 6:14:58 AM org.apache.commons.betwixt.versioning.TestVersioning testWrite4 [junit] INFO: testWrite1() complete [junit] - ---
[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 7 projects, and has been outstanding for 50 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 - 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-20062007.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: 2 mins 40 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-20062007 -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-20062007.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-20062007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-20062007.jar:/usr/local/gump/public/workspace/junit/dist/junit-20062007.jar - [junit] Jun 20, 2007 6:14:58 AM org.apache.commons.betwixt.versioning.VersioningStrategy checkVersionUntil [junit] INFO: value=null [junit] Jun 20, 2007 6:14:58 AM org.apache.commons.betwixt.versioning.VersioningStrategy checkVersionUntil [junit] INFO: version=3 [junit] Jun 20, 2007 6:14:58 AM org.apache.commons.betwixt.versioning.VersioningStrategy debugOptions [junit] INFO: Names: [junit] Jun 20, 2007 6:14:58 AM org.apache.commons.betwixt.versioning.VersioningStrategy debugOptions [junit] INFO: 0: version-from=2 [junit] Jun 20, 2007 6:14:58 AM org.apache.commons.betwixt.versioning.VersioningStrategy checkVersionUntil [junit] INFO: No attribute Version until [junit] Jun 20, 2007 6:14:58 AM org.apache.commons.betwixt.versioning.VersioningStrategy suppress [junit] INFO: Showing element [junit] Jun 20, 2007 6:14:58 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] Jun 20, 2007 6:14:58 AM org.apache.commons.betwixt.versioning.TestVersioning testWrite4 [junit] INFO: testWrite1() complete [junit] - ---
Re: [vfs] HttpClient 3.x Compatibility?
Hi James! Help! I'm in jar hell (again). Apparently, HttpClient v2.0.2 and 3.0.1(current stable release) are not binary compatible. They introduced setParams()/getParams() methods into the HttpConnectionManager interface. However, VFS' WebdavConnectionManager doesn't implement these methods and it can't unless it upgrades its dependency to HttpClient 3.0.1, since the property type of the params property isn't introduced until 3.0.1. This causes a major issue, because my project requires the 3.0.1 version of HttpClient, but we're also using VFS' webdav support, so we're required to stick with HttpClient 2.0.2 to resolve this issue. Any suggestions? Looks like we have to find out whats the problem is with webdav and the latest httpclient. Do you have any status on that? Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] HttpClient 3.x Compatibility?
I didn't know there was an issue between the two. I know that I can update the dependency in the pom and change the WebdavConnectionManager to have the required methods and it works (at least it compiles). I don't have the integration test environment set up, though. On 6/20/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi James! Help! I'm in jar hell (again). Apparently, HttpClient v2.0.2 and 3.0.1(current stable release) are not binary compatible. They introduced setParams()/getParams() methods into the HttpConnectionManager interface. However, VFS' WebdavConnectionManager doesn't implement these methods and it can't unless it upgrades its dependency to HttpClient 3.0.1, since the property type of the params property isn't introduced until 3.0.1. This causes a major issue, because my project requires the 3.0.1 version of HttpClient, but we're also using VFS' webdav support, so we're required to stick with HttpClient 2.0.2 to resolve this issue. Any suggestions? Looks like we have to find out whats the problem is with webdav and the latest httpclient. Do you have any status on that? Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] HttpClient 3.x Compatibility?
Hi James! I didn't know there was an issue between the two. I know that I can update the dependency in the pom and change the WebdavConnectionManager to have the required methods and it works (at least it compiles). I don't have the integration test environment set up, though. Ok, so I'll give it a try. Could you attach the patch to a jira issue please. Btw, in the VFS HEAD the WebdavConnectionManager has been moved to the http filesystem and renamed to ThreadLocalHttpConnectionManager as it turned out that it is useful there too. Ciao, Mario On 6/20/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi James! Help! I'm in jar hell (again). Apparently, HttpClient v2.0.2 and 3.0.1(current stable release) are not binary compatible. They introduced setParams()/getParams() methods into the HttpConnectionManager interface. However, VFS' WebdavConnectionManager doesn't implement these methods and it can't unless it upgrades its dependency to HttpClient 3.0.1, since the property type of the params property isn't introduced until 3.0.1. This causes a major issue, because my project requires the 3.0.1 version of HttpClient, but we're also using VFS' webdav support, so we're required to stick with HttpClient 2.0.2 to resolve this issue. Any suggestions? Looks like we have to find out whats the problem is with webdav and the latest httpclient. Do you have any status on that? Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- mit freundlichen Grüßen Mario Ivankovits Software Engineering OPS EDV VertriebsgesmbH A-1120 Wien, Michael-Bernhard-Gasse 10 Firmenbuch Nr.: FN51233v, Handelsgericht Wien Tel.: +43-1-8938810; Fax: +43-1-8938810/3700 http://www.ops.co.at E-Mail: [EMAIL PROTECTED] Skype: mario_ivankovits - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VFS] RE: [EMAIL PROTECTED]: Project ivy (in module ivy) failed
I cross-post this mail to ivy-dev and commons-dev because it concerns both community. Sorry if some of you received the mail twice. I traced back the failure in the gump build of ivy up to [1]. A class that we use in VFS has been renamed. I'm not sure what we should do: 1. Adapt the ivy code to the new class. But then, we might have to make our own build of vfs if we want to release before the next vfs release. (Note that ivy plan to make a release in +/- 1 month.) 2. Keep the code that we have in ivy and keep the gump build failing? But then we could not rely on it has a safety net that run unit test, and it might also be boring for the project depending on ivy in gump. 3. Replace our dependency to commons-vfs-sandbox in gump by a static dependency version. Note that it might also be a good opportunity to fix a problem that we have in ivy : We are still dependent on an unreleased version of commons-vfs [2] because we are using classes from commons-vfs-sandbox that have not yet been released (as far as we know). [1] http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/200706.mbox/%3 [EMAIL PROTECTED] [2] http://www.jaya.free.fr/ivyrep/apache/commons-vfs/20060920/ Gilles -Original Message- From: Gump Integration Build [mailto:[EMAIL PROTECTED] Sent: mercredi 20 juin 2007 7:10 To: [EMAIL PROTECTED] Subject: [EMAIL PROTECTED]: Project ivy (in module ivy) 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 ivy has an issue affecting its community integration. This issue affects 11 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - antbook-diary-core : Examples to go with Java Development with Ant - antbook-sections : Examples to go with Java Development with Ant - cddlm : Configuration and Deployment of Grid Applications and System... - ivy : Ivy Core - ivy-tests : Ivy is a tool for managing (recording, tracking, resolving a... - smartfrog : Smartfrog: Application Deployment from HP Laboratories - smartfrog-components : Smartfrog: Application Deployment from HP Laboratories - smartfrog-tasks : Smartfrog: Application Deployment from HP Laboratories - smartfrog-tasks-test : Smartfrog: Application Deployment from HP Laboratories - smartfrog-test : Smartfrog: Application Deployment from HP Laboratories - smartfrog-testharness : Smartfrog: Application Deployment from HP Laboratories Full details are available at: http://vmgump.apache.org/gump/public/ivy/ivy/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason build failed -DEBUG- Extracted fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/ivy/ivy/gump_work/build_ivy_ivy.html Work Name: build_ivy_ivy (Type: Build) Work ended in a state of : Failed Elapsed: 13 secs Command Line: /opt/jdk1.5/bin/java -Djava.awt.headless=true org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dfinal.name=ivy-19062007.jar -Doffline=true - Dno.resolve=true -Dfinal.core.name=ivy-core-19062007.jar jar [Working Directory: /usr/local/gump/public/workspace/ivy] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ivy/build/class es/ant:/usr/local/gump/public/workspace/ivy/build/classes/core:/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/loca l/gump/packages/junit3.8.1/junit.jar:/usr/local/gump/public/workspace/xml- commons/java/build/resolver.jar:/usr/local/gump/public/workspace/jakarta- commons/httpclient/dist/commons- httpclient.jar:/usr/local/gump/public/workspace/commons-cli- 1.0.x/target/commons-cli- 19062007.jar:/usr/local/gump/public/workspace/jakarta-oro/jakarta-oro- 19062007.jar:/usr/local/gump/public/workspace/jakarta- commons/vfs/target/commons-vfs- 19062007.jar:/usr/local/gump/public/workspace/jakarta- commons/vfs/sandbox/target/commons-vfs-sandbox- 19062007.jar:/usr/local/gump/public/workspace/jakarta- slide/webdavclient/dist/lib/jakarta-slide-webdavlib- 19062007.jar:/usr/local/gump/packages/jsch/jsch-0.1.28.jar
[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 30 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. -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: 18 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-20062007.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-20062007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-20062007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-20062007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-20062007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-20062007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-20062007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-20062007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-20062007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-20062007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-20062007.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 org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:102)
[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 30 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. -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: 18 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-20062007.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-20062007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-20062007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-20062007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-20062007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-20062007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-20062007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-20062007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-20062007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-20062007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-20062007.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 org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:102)
[EMAIL PROTECTED]: Project commons-jelly-tags-jaxme (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-jaxme has an issue affecting its community integration. This issue affects 1 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-jelly-tags-jaxme : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-jaxme-20062007.jar] identifier set to project name -DEBUG- Dependency on packaged-jaxme exists, no need to add for property maven.jar.jaxme. -DEBUG- Dependency on packaged-jaxme exists, no need to add for property maven.jar.jaxme-js. -DEBUG- Dependency on packaged-jaxme exists, no need to add for property maven.jar.jaxme-xs. -DEBUG- Dependency on packaged-jaxme exists, no need to add for property maven.jar.jaxme-api. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jaxme/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jaxme/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jaxme/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jaxme/target/test-reports -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/gump_work/build_commons-jelly_commons-jelly-tags-jaxme.html Work Name: build_commons-jelly_commons-jelly-tags-jaxme (Type: Build) Work ended in a state of : Failed Elapsed: 20 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jaxme] CLASSPATH: /opt/jdk1.5/lib/tools.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-20062007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-20062007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-20062007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-20062007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xmlunit/target/commons-jelly-tags-xmlunit-20062007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-20062007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-20062007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-20062007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-20062007.jar:/usr/local/gump/packages/ws-jaxme-0.5/lib/jaxme2-0.5.jar:/usr/local/gump/packages/ws-jaxme-0.5/lib/jaxmeapi-0.5.jar:/usr/local/gump/packages/ws-jaxme-0.5/lib/jaxmejs-0.5.jar:/usr/local/gump/packages/ws-jaxme-0.5/lib/jaxmexs-0.5.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/usr/local/gump/public/workspace/xmlunit/build/lib/xmlunit-20062007.jar - [javac] symbol : variable super [javac] location: class org.apache.ws.jaxme.examples.misc.address.impl.AddressTypeHandler [javac] super.startElement(pNamespaceURI, pLocalName, pQName, pAttr); [javac] ^ [javac] /x1/gump/public/workspace/commons-jelly/jelly-tags/jaxme/src/test/org/apache/ws/jaxme/examples/misc/address/impl/AddressTypeHandler.java:273: cannot find symbol [javac] symbol : variable super [javac] location: class org.apache.ws.jaxme.examples.misc.address.impl.AddressTypeHandler [javac] super.endElement(pNamespaceURI, pLocalName, pQName); [javac] ^ [javac] /x1/gump/public/workspace/commons-jelly/jelly-tags/jaxme/src/test/org/apache/ws/jaxme/examples/misc/address/impl/AddressTypeHandler.java:282: cannot find symbol [javac] symbol : method getResult() [javac] location: class org.apache.ws.jaxme.examples.misc.address.impl.AddressTypeHandler [javac] org.apache.ws.jaxme.examples.misc.address.AddressType _1 = (org.apache.ws.jaxme.examples.misc.address.AddressType) getResult(); [javac]
[EMAIL PROTECTED]: Project commons-jelly-tags-jaxme (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-jaxme has an issue affecting its community integration. This issue affects 1 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-jelly-tags-jaxme : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-jaxme-20062007.jar] identifier set to project name -DEBUG- Dependency on packaged-jaxme exists, no need to add for property maven.jar.jaxme. -DEBUG- Dependency on packaged-jaxme exists, no need to add for property maven.jar.jaxme-js. -DEBUG- Dependency on packaged-jaxme exists, no need to add for property maven.jar.jaxme-xs. -DEBUG- Dependency on packaged-jaxme exists, no need to add for property maven.jar.jaxme-api. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jaxme/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jaxme/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jaxme/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jaxme/target/test-reports -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/gump_work/build_commons-jelly_commons-jelly-tags-jaxme.html Work Name: build_commons-jelly_commons-jelly-tags-jaxme (Type: Build) Work ended in a state of : Failed Elapsed: 20 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jaxme] CLASSPATH: /opt/jdk1.5/lib/tools.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-20062007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-20062007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-20062007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-20062007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xmlunit/target/commons-jelly-tags-xmlunit-20062007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-20062007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-20062007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-20062007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-20062007.jar:/usr/local/gump/packages/ws-jaxme-0.5/lib/jaxme2-0.5.jar:/usr/local/gump/packages/ws-jaxme-0.5/lib/jaxmeapi-0.5.jar:/usr/local/gump/packages/ws-jaxme-0.5/lib/jaxmejs-0.5.jar:/usr/local/gump/packages/ws-jaxme-0.5/lib/jaxmexs-0.5.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/usr/local/gump/public/workspace/xmlunit/build/lib/xmlunit-20062007.jar - [javac] symbol : variable super [javac] location: class org.apache.ws.jaxme.examples.misc.address.impl.AddressTypeHandler [javac] super.startElement(pNamespaceURI, pLocalName, pQName, pAttr); [javac] ^ [javac] /x1/gump/public/workspace/commons-jelly/jelly-tags/jaxme/src/test/org/apache/ws/jaxme/examples/misc/address/impl/AddressTypeHandler.java:273: cannot find symbol [javac] symbol : variable super [javac] location: class org.apache.ws.jaxme.examples.misc.address.impl.AddressTypeHandler [javac] super.endElement(pNamespaceURI, pLocalName, pQName); [javac] ^ [javac] /x1/gump/public/workspace/commons-jelly/jelly-tags/jaxme/src/test/org/apache/ws/jaxme/examples/misc/address/impl/AddressTypeHandler.java:282: cannot find symbol [javac] symbol : method getResult() [javac] location: class org.apache.ws.jaxme.examples.misc.address.impl.AddressTypeHandler [javac] org.apache.ws.jaxme.examples.misc.address.AddressType _1 = (org.apache.ws.jaxme.examples.misc.address.AddressType) getResult(); [javac]
[Jakarta-commons Wiki] Update of Email by BenSpeakmon
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 BenSpeakmon: http://wiki.apache.org/jakarta-commons/Email The comment on the change is: fleshed out release plan -- = Release Plan = - A commons-email 1.1 release is in the planning stages. + In addition to performing steps in http://jakarta.apache.org/commons/releases/prepare.html, also do the following: + * Get maven 2 build to the point where it can do everything the m1 build does + * Remove the m1 build + * Do a javadoc pass; leave no public/protected member undocumented + * Deprecate unused public/protected members + * Run complete build, test, and package cycle on JDK 1.4, 5, and 6 + * Upload my gpg key for signing the release + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (DBCP-216) Improvement of error recovery in KeyedCPDSConnectionFactory
[ https://issues.apache.org/jira/browse/DBCP-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506620 ] Phil Steitz commented on DBCP-216: -- Patch looks correct and appropriate to me, subject to the comments below. Similar changes should probably be made to CPDSConnectionFactory. Regarding 2., with current backing pool (o.a.c.pool.GenericKeyedObjectPool), the destroy - invalidate change (2.) will only work for *active* (i.e., checked out) connections and in this case it is necessary, but not to remove from the pool, but to maintain integrity of the active count. Unfortunately, the contract of the pool's invalidate method only applies to objects that have been borrowed from the pool, so if the (exception-generating) connectionClosed event originates from from an idle connection, this will not work. This should not happen in general though, since these events should come from handles from checked out connections. Test cases illustrating the problem in this ticket should be added before committing the patch. Improvement of error recovery in KeyedCPDSConnectionFactory --- Key: DBCP-216 URL: https://issues.apache.org/jira/browse/DBCP-216 Project: Commons Dbcp Issue Type: Improvement Affects Versions: 1.2.2 Environment: Windows XP, Java 1.5.0_06-b05, Sybase ASE 12.5.4, jConnect 6.0.5 EBF 13862, Commons Pool 1.3 Reporter: Marcos Sanz Fix For: 1.3 Attachments: KeyedCPDSConnectionFactory.java.diff Attached you'll find a patch that improves the recovery of the class in different error situations. 1. The addition of removeConnectionEventListener() in destroyObject() ensures that the listener is removed, which is not guaranteed to have happened upon call of destroyObject(). We are for sure not interested any more in events, since we are about to destroy. 2. The same addition is made to connectionClosed(). Additionally, we have substituted there the call to destroyObject() with a call to pool.invalidateObject(). This is necessary because otherwise the object is destroyed but not removed from the pool. 3. The same substitution is made in connectionErrorOccurred(), otherwise the object might remain in the pool. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (DBCP-97) setAutoCommit(true) when returning connection to the pool
[ https://issues.apache.org/jira/browse/DBCP-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated DBCP-97: Fix Version/s: 1.3 setAutoCommit(true) when returning connection to the pool - Key: DBCP-97 URL: https://issues.apache.org/jira/browse/DBCP-97 Project: Commons Dbcp Issue Type: Bug Affects Versions: Nightly Builds Environment: Operating System: All Platform: All Reporter: Dirk Verbeeck Fix For: 1.3 From the Struts user list: [OT] RE: Stackoverflow after DB inactivity (MySQL reconnect problem) http://www.mail-archive.com/[EMAIL PROTECTED]/msg70196.html Giving a hint to the database driver that you don't need long running transactions makes sense. setAutoCommit(true) should be added to PoolableConnectionFactory.passivateObject -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (DBCP-225) getConnection / borrowObject fails with NullPointerException
[ https://issues.apache.org/jira/browse/DBCP-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated DBCP-225: - Fix Version/s: 1.3 getConnection / borrowObject fails with NullPointerException Key: DBCP-225 URL: https://issues.apache.org/jira/browse/DBCP-225 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.2.1, 1.2.2 Environment: Solaris 10, Oracle 10g RAC Reporter: Alexei Samonov Fix For: 1.3 We use dbcp PoolingDataSource in Solaris/Oracle 10g RAC environment and our getConnection calls fail sporadically with the following stack trace (1.2.1) Caused by: org.apache.commons.dbcp.SQLNestedException: Cannot get a connection, pool exhausted at org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:103) at org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:540) ... more Caused by: java.util.NoSuchElementException: Could not create a validated object, cause: null at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:806) at org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:95) ... 24 more This is definitely not a pool exhausted situation, it is just being reported as pool exhausted. Since NoSuchElementException that you use does not allow cause, only Exception message (null) is being printed. With some debugging I was able to recover the root exception: java.lang.NullPointerException at org.apache.commons.dbcp.DelegatingConnection.setAutoCommit(DelegatingConnection.java:268) at org.apache.commons.dbcp.PoolableConnectionFactory.activateObject(PoolableConnectionFactory.java:368) at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:786) at org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:95) at org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:540) ... Looks like it is trying to borrow/validate DelegatingConnection which delegate is null. Hoping to resolve the issue we upgraded to 1.2.2 but it did not help. Here is is an exception stack trace from 1.2.2: org.apache.commons.dbcp.SQLNestedException: Cannot get a connection, pool error Could not create a validated object, cause: null at org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:104) at org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:880) ... more Caused by: java.util.NoSuchElementException: Could not create a validated object, cause: null at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:871) at org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:96) ... 28 more We use the following dbcp properties: autoCommit=false readOnly=false maxActive=200 maxIdle=20 minIdle=10 minEvictableIdleIime=30 maxWait=200 accessToUnderlyingConnectionAllowed=true validationQuery=SELECT 1 FROM DUAL ConnectionCachingEnabled=true FastConnectionFailoverEnabled=true I could not find the existing reported dbcp/object pool bug but I see similar reports on the web, for example http://forum.java.sun.com/thread.jspa?threadID=713200messageID=4124915 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (CONFIGURATION-281) JNDIConfiguration::recursiveGetKeys goes out of stack
JNDIConfiguration::recursiveGetKeys goes out of stack - Key: CONFIGURATION-281 URL: https://issues.apache.org/jira/browse/CONFIGURATION-281 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.2 Environment: Websphere 5.1 Reporter: Michiel Kalkman Fix For: 1.5 There can be cycles in contexts. Websphere 5.1 certainly does have them. When getKeys() is called on a JNDIConfiguration, eventually recursiveGetKeys() is called, which calls itself for every subcontext. This will never stop if there is a cycle. I would like to suggest the following changes to recursiveGetKeys() to fix this: 1) check for each subcontext if it has been processed before. If so, don't process it. An additional stack argument to recursiveGetKeys() should do the trick here. 2) a maxDepth attribute, like jndi maxDepth=4/. If the number of subcontexts is equal to maxDepth, stop processing. The maxDepth attribute should be optional of course, and have a default value like 911or so. The stack argument could be used to check the amount of subcontexts processed. Because I want to be able to dump the configuration for debugging purposes, this item is of somewhat importance to me. I tested this in 1.2 at work, so I cannot easily test this against 1.4. But as the code of 1.4 seems to be more or less the same, I think the problem still exists. -- 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: r549181 - /jakarta/commons/proper/email/trunk/pom.xml
Author: bspeakmon Date: Wed Jun 20 11:31:33 2007 New Revision: 549181 URL: http://svn.apache.org/viewvc?view=revrev=549181 Log: - use org.apache.commons for groupId Modified: jakarta/commons/proper/email/trunk/pom.xml Modified: jakarta/commons/proper/email/trunk/pom.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/email/trunk/pom.xml?view=diffrev=549181r1=549180r2=549181 == --- jakarta/commons/proper/email/trunk/pom.xml (original) +++ jakarta/commons/proper/email/trunk/pom.xml Wed Jun 20 11:31:33 2007 @@ -25,7 +25,7 @@ version3/version /parent modelVersion4.0.0/modelVersion -groupIdcommons-email/groupId +groupIdorg.apache.commons/groupId artifactIdcommons-email/artifactId version1.1-SNAPSHOT/version nameCommons-Email/name @@ -275,5 +275,17 @@ /plugin /plugins /build + +reporting +plugins +plugin +groupIdorg.apache.maven.plugins/groupId +artifactIdmaven-checkstyle-plugin/artifactId +configuration +configLocationconf/checkstyle.xml/configLocation +/configuration +/plugin +/plugins +/reporting /project - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r549182 - /jakarta/commons/proper/email/trunk/STATUS.html
Author: bspeakmon Date: Wed Jun 20 11:31:46 2007 New Revision: 549182 URL: http://svn.apache.org/viewvc?view=revrev=549182 Log: - add self to STATUS Modified: jakarta/commons/proper/email/trunk/STATUS.html Modified: jakarta/commons/proper/email/trunk/STATUS.html URL: http://svn.apache.org/viewvc/jakarta/commons/proper/email/trunk/STATUS.html?view=diffrev=549182r1=549181r2=549182 == --- jakarta/commons/proper/email/trunk/STATUS.html (original) +++ jakarta/commons/proper/email/trunk/STATUS.html Wed Jun 20 11:31:46 2007 @@ -89,6 +89,7 @@ lia href=mailto:jmcnally at apache.orgJohn McNally/a (Emeritus Committer)/li lia href=mailto:jon at apache.orgJon Stevens/a (Emeritus Committer)/li lia href=mailto:dion at apache.orgdIon Gillard/a (Commons Committer)/li +lia href=mailto:bspeakmon at apache.orgBen Speakmon/a (Commons Committer)/li /ul /body - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r549181 - /jakarta/commons/proper/email/trunk/pom.xml
Changing the group id is going to cause problems (see archives for past discussions) - I believe we had settled on not changing group ids as it seemed the only solution ATM that didn't cause pain. Niall On 6/20/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: bspeakmon Date: Wed Jun 20 11:31:33 2007 New Revision: 549181 URL: http://svn.apache.org/viewvc?view=revrev=549181 Log: - use org.apache.commons for groupId Modified: jakarta/commons/proper/email/trunk/pom.xml Modified: jakarta/commons/proper/email/trunk/pom.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/email/trunk/pom.xml?view=diffrev=549181r1=549180r2=549181 == --- jakarta/commons/proper/email/trunk/pom.xml (original) +++ jakarta/commons/proper/email/trunk/pom.xml Wed Jun 20 11:31:33 2007 @@ -25,7 +25,7 @@ version3/version /parent modelVersion4.0.0/modelVersion -groupIdcommons-email/groupId +groupIdorg.apache.commons/groupId artifactIdcommons-email/artifactId version1.1-SNAPSHOT/version nameCommons-Email/name @@ -275,5 +275,17 @@ /plugin /plugins /build + +reporting +plugins +plugin +groupIdorg.apache.maven.plugins/groupId +artifactIdmaven-checkstyle-plugin/artifactId +configuration +configLocationconf/checkstyle.xml/configLocation +/configuration +/plugin +/plugins +/reporting /project - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r549181 - /jakarta/commons/proper/email/trunk/pom.xml
In my weak defense, I was trying to copy what had been done for other recent m2 releases (specifically jci). I seem to be doing a fine imitation of a bull in a china shop. I'll back it out. On 6/20/07, Niall Pemberton [EMAIL PROTECTED] wrote: Changing the group id is going to cause problems (see archives for past discussions) - I believe we had settled on not changing group ids as it seemed the only solution ATM that didn't cause pain. Niall On 6/20/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: bspeakmon Date: Wed Jun 20 11:31:33 2007 New Revision: 549181 URL: http://svn.apache.org/viewvc?view=revrev=549181 Log: - use org.apache.commons for groupId Modified: jakarta/commons/proper/email/trunk/pom.xml Modified: jakarta/commons/proper/email/trunk/pom.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/email/trunk/pom.xml?view=diffrev=549181r1=549180r2=549181 == --- jakarta/commons/proper/email/trunk/pom.xml (original) +++ jakarta/commons/proper/email/trunk/pom.xml Wed Jun 20 11:31:33 2007 @@ -25,7 +25,7 @@ version3/version /parent modelVersion4.0.0/modelVersion -groupIdcommons-email/groupId +groupIdorg.apache.commons/groupId artifactIdcommons-email/artifactId version1.1-SNAPSHOT/version nameCommons-Email/name @@ -275,5 +275,17 @@ /plugin /plugins /build + +reporting +plugins +plugin +groupIdorg.apache.maven.plugins/groupId +artifactIdmaven-checkstyle-plugin/artifactId +configuration +configLocationconf/checkstyle.xml/configLocation +/configuration +/plugin +/plugins +/reporting /project - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r549192 - /jakarta/commons/proper/email/trunk/pom.xml
Author: bspeakmon Date: Wed Jun 20 12:00:58 2007 New Revision: 549192 URL: http://svn.apache.org/viewvc?view=revrev=549192 Log: - back out groupId change, since it'll trash unforeseen things Modified: jakarta/commons/proper/email/trunk/pom.xml Modified: jakarta/commons/proper/email/trunk/pom.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/email/trunk/pom.xml?view=diffrev=549192r1=549191r2=549192 == --- jakarta/commons/proper/email/trunk/pom.xml (original) +++ jakarta/commons/proper/email/trunk/pom.xml Wed Jun 20 12:00:58 2007 @@ -25,7 +25,7 @@ version3/version /parent modelVersion4.0.0/modelVersion -groupIdorg.apache.commons/groupId +groupIdcommons-email/groupId artifactIdcommons-email/artifactId version1.1-SNAPSHOT/version nameCommons-Email/name - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
fileUpload bug report
Hi there!
I'm quite sure I found a bug in the fileUpload module:
In one of my projects I need to upload a file to the server. I used the
following code:
if (ServletFileUpload.isMultipartContent(req)) {
DiskFileItemFactory factory = new DiskFileItemFactory();
//factory.setSizeThreshold(0);
ServletFileUpload upload = new ServletFileUpload(factory);
try {
// Thread.sleep(10);
List items = upload.parseRequest(req);
Iterator iter = items.iterator();
while (iter.hasNext()) {
FileItem item = (FileItem) iter.next();
String fieldName = item.getFieldName();
if (item.isFormField()) {
// add logger for info about form input type=file
// fields
} else {
File file = null;
String ref = null;
do {
ref = generateFileReferenceId();
file = new File(getPath() + WEB-INF +
File.separator + files + File.separator + ref);
} while (file.exists());
item.write(file);
The file I used for testing had a size of 29 bytes. Directly after
restarting the server the above code usually successfully stores the
file on the server. But the second and all following trials usually
failed. A file with this name is stored on the server but has a size of
0 bytes. Tests with much bigger files (~600 kb) were always succesful.
Inserting the line Thread.sleep(10); (see above in the code)
significantly increases the chance of correct behaviour and with 500 ms
the error didn't occur anymore. Alternatively setting a breakpoint to
the same line works too. The sleep-command or breakpoint has to be
somewhere above the parseRequest-command to avoid the error.
Debugging showed me that the code-behaviour on this level is completely
identical. The only difference I recognized was that the
DeferredOutputStream of the second item (the one containing my file -
the first one is a formfield and seemed to be always correct) had a size
of 0.
Changing the threshold of the factory (see other commented line above)
had no effect except that setting the limit to 0 seemed to cause the
error with the small file constantly (with the bigger file still working
fine). Setting it to other values smaller 29 (for example 10) had no effect.
A colleague using the same code and same file had no problems at all.
I'm running a Windows Vista.
I will use the above code with the sleep-workaround for at least a few
days so I might be able to react on further questions and suggestions.
Best regards,
Nils
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (DBCP-212) PoolingDataSource closes physical connections
[ https://issues.apache.org/jira/browse/DBCP-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506646 ] Phil Steitz commented on DBCP-212: -- PoolableConnectionFactory.makeObject() has been synchronized since the initial commit. Synchronization of validateObject was removed in r132110 in response to BZ 25096. Can anyone else see a reason that this synchronization is necessary? PoolingDataSource closes physical connections - Key: DBCP-212 URL: https://issues.apache.org/jira/browse/DBCP-212 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.2.2 Environment: Windows XP, Java 1.5.0_06-b05, Sybase ASE 12.5.4, jConnect 6.0.5 EBF 13862, Commons Pool 1.3 Reporter: Marcos Sanz Fix For: 1.3 Attachments: DBCPtester.java, DBCPtester.java, output.txt By executing the attached program and monitoring the process id of the physical connections at the database server, it is possible to demonstrate that the connections are being actually physically closed and reopened by the application at a very high rate. -- 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: [RESULT] 3rd attempt: Release commons-io 1.3.2
On 6/20/07, Phil Steitz [EMAIL PROTECTED] wrote: It is up to the RM, but with a -1 from a major contributor to the code base, I would personally not push out the release. FWIW, as mentioned on other threads, I agree with Stephen on the version number issue. The problem is simply that votes for releases on commons drive me sick. It is not the exception, but the standard, that people demand changes (which they of course assume that the RM will do) and use a -1 to enforce their opinion. I have a different opinion in this matter. I see absolutely no problem with a compiler warning as long as I may drop in the binary to a running system: *That* is what I call binary compatible and what assume to be the contract for binary releases. My point of view is that he or she who demands such work (going through the docs and find all occurrencies of 1.3.2 and such is a nontrivial work and will easily take two hours or so) should be ready to do it for himself *or* leave it up to me to decide. Jochen -- Besides, manipulating elections is under penalty of law, resulting in a preventative effect against manipulating elections. The german government justifying the use of electronic voting machines and obviously believing that we don't need a police, because all illegal actions are forbidden. http://dip.bundestag.de/btd/16/051/1605194.pdf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (POOL-98) Make GenericObjectPool better extensible
[
https://issues.apache.org/jira/browse/POOL-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506659
]
Phil Steitz commented on POOL-98:
-
I don't think we want to expose the _pool, since this is actually a linked list
of idle objects, so exposing it is not that useful and would really tie GOP to
the current internal implementation if we allowed subclasses to depend on it.
Other than the current counters numActive, numIdle, and the pool properties,
what would be most useful for management?
Make GenericObjectPool better extensible
Key: POOL-98
URL: https://issues.apache.org/jira/browse/POOL-98
Project: Commons Pool
Issue Type: Improvement
Affects Versions: 1.3
Reporter: Henning Schmiedehausen
Priority: Minor
The current implementation of GenericObjectPool encapsulates the _pool
object and there is no way to get it directly, which makes some things
like JMX pool monitoring a bit awkward.
Would it be possible to either make _pool protected or add a method
protected Collection getInternalPool() {
return _pool;
}
or something like that to the GenericObjectPool implementation (and
probably others, but that is the one that bites me most... :-) )
This would make extending the GenericObjectPool much easier.
--
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: r549221 - /jakarta/commons/proper/email/trunk/conf/checkstyle.xml
Author: bspeakmon
Date: Wed Jun 20 13:28:42 2007
New Revision: 549221
URL: http://svn.apache.org/viewvc?view=revrev=549221
Log:
- remove basedir property reference; tested on java 1.4 with m1 and m2 and
works fine.
Modified:
jakarta/commons/proper/email/trunk/conf/checkstyle.xml
Modified: jakarta/commons/proper/email/trunk/conf/checkstyle.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/email/trunk/conf/checkstyle.xml?view=diffrev=549221r1=549220r2=549221
==
--- jakarta/commons/proper/email/trunk/conf/checkstyle.xml (original)
+++ jakarta/commons/proper/email/trunk/conf/checkstyle.xml Wed Jun 20 13:28:42
2007
@@ -67,7 +67,7 @@
!-- Checks for Headers --
!-- See http://checkstyle.sf.net/config_header.html --
module name=Header
-property name=headerFile value=${basedir}/conf/HEADER.txt/
+property name=headerFile value=conf/HEADER.txt/
property name=ignoreLines value=2/
/module
@@ -115,9 +115,9 @@
!-- See http://checkstyle.sf.net/config_blocks.html --
module name=AvoidNestedBlocks/
module name=EmptyBlock
- property name=option value=text/
- property name=tokens value=LITERAL_CATCH/
- /module
+property name=option value=text/
+property name=tokens value=LITERAL_CATCH/
+/module
module name=LeftCurly
property name=option value=nl/
/module
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-281) JNDIConfiguration::recursiveGetKeys goes out of stack
[ https://issues.apache.org/jira/browse/CONFIGURATION-281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506670 ] Oliver Heger commented on CONFIGURATION-281: I did some testing and could reproduce the problem with mock objects. 1) fixed the problem, assuming that the involved Context objects have a meaningful implementation of equals() and hashCode(). Why would 2) be necessary in addition to 1)? JNDIConfiguration::recursiveGetKeys goes out of stack - Key: CONFIGURATION-281 URL: https://issues.apache.org/jira/browse/CONFIGURATION-281 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.2 Environment: Websphere 5.1 Reporter: Michiel Kalkman Fix For: 1.5 There can be cycles in contexts. Websphere 5.1 certainly does have them. When getKeys() is called on a JNDIConfiguration, eventually recursiveGetKeys() is called, which calls itself for every subcontext. This will never stop if there is a cycle. I would like to suggest the following changes to recursiveGetKeys() to fix this: 1) check for each subcontext if it has been processed before. If so, don't process it. An additional stack argument to recursiveGetKeys() should do the trick here. 2) a maxDepth attribute, like jndi maxDepth=4/. If the number of subcontexts is equal to maxDepth, stop processing. The maxDepth attribute should be optional of course, and have a default value like 911or so. The stack argument could be used to check the amount of subcontexts processed. Because I want to be able to dump the configuration for debugging purposes, this item is of somewhat importance to me. I tested this in 1.2 at work, so I cannot easily test this against 1.4. But as the code of 1.4 seems to be more or less the same, I think the problem still exists. -- 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]
[dbcp] [pool] Roadmap ideas
There are still quite a few bugs open against [dbcp] and [pool]. We also have an unreleased, improved pool impl in the compositepool package. I would like to toss out some ideas for discussion about where to go with these two components and guage interest in helping out. Recent releases: [dbcp] - The 1.2.2 release was a conservative bug fix release - minimal change while addressing some bugs and upgrading to [pool] 1.3. [pool] - 1.3 less conservative vis a vis 1.2, several bug fixes, including some added synchronization to fix thread safety issues. Next releases: [dbcp] - 1.3 close as many of the 1.3-marked bugs as possible without the new pool impl and add instrumentation using JDK logging, therefore increasing required JDK level to 1.4. Resolution of some issues involving close behavior may have to be deferred to rework of pool-dbcp connection (move to CompositePools). Continue dependency on [pool]'s GOP in this release. More aggressive bug fixing, performance improvement - more testing, public beta required. Need to talk about a strategy for that. [pool] - push out a 1.3.1 including fixes applied since 1.3 and if possible, fixes for POOL-97, POOL-93, with dbcp 1.3 depending on this. The idea here is the 1.3.x branches of [pool] and [dbcp] continue to support existing clients with full backward compatibility at JDK 1.4 level, providing bug fixes but no new functionality or APIs. 2.0's: (Work could begin now on branches, concurrently with 1.x releases above) [dbcp]: 2.0 move to CompositePool backing and add JDBC 4 support, increasing JDK level to 1.5 and removing currently deprecated classes. If 1.x-incompatible changes are necessary (not obvious at this point that they are), rename affected packages dbcp2. [pool]: 2.0 release compositepool package, resolve open pool bugs. JDK level upped to 1.5. Investigate use of JDK concurrency package to improve performance and/or resolve some open pool issues. Comments, suggestions, *volunteers*? Thanks! Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-281) JNDIConfiguration::recursiveGetKeys goes out of stack
[ https://issues.apache.org/jira/browse/CONFIGURATION-281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506696 ] Michiel Kalkman commented on CONFIGURATION-281: --- Cool, thanks. I guess #2 is less important, and therefore not necessary, however I just thought that adding maxDepth might reduce the max size of a jndi context tree, and therefore reduce the nr of keys that are returned. Just in case some app decides to be creative with jndi contexts. JNDIConfiguration::recursiveGetKeys goes out of stack - Key: CONFIGURATION-281 URL: https://issues.apache.org/jira/browse/CONFIGURATION-281 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.2 Environment: Websphere 5.1 Reporter: Michiel Kalkman Fix For: 1.5 There can be cycles in contexts. Websphere 5.1 certainly does have them. When getKeys() is called on a JNDIConfiguration, eventually recursiveGetKeys() is called, which calls itself for every subcontext. This will never stop if there is a cycle. I would like to suggest the following changes to recursiveGetKeys() to fix this: 1) check for each subcontext if it has been processed before. If so, don't process it. An additional stack argument to recursiveGetKeys() should do the trick here. 2) a maxDepth attribute, like jndi maxDepth=4/. If the number of subcontexts is equal to maxDepth, stop processing. The maxDepth attribute should be optional of course, and have a default value like 911or so. The stack argument could be used to check the amount of subcontexts processed. Because I want to be able to dump the configuration for debugging purposes, this item is of somewhat importance to me. I tested this in 1.2 at work, so I cannot easily test this against 1.4. But as the code of 1.4 seems to be more or less the same, I think the problem still exists. -- 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: [RESULT] 3rd attempt: Release commons-io 1.3.2
Jochen Wiedmann jochen.wiedmann at gmail.com writes: The problem is simply that votes for releases on commons drive me sick. It is not the exception, but the standard, that people demand changes (which they of course assume that the RM will do) and use a -1 to enforce their opinion. I have a different opinion in this matter. I see absolutely no problem with a compiler warning as long as I may drop in the binary to a running system: *That* is what I call binary compatible and what assume to be the contract for binary releases. Amen. Especially since the official versioning guidelines [1] consider deprecation as a fully compatible change while a point release only requires interface compatibility. What's actually the reasoning to demand a minor release because of a deprecation? Joerg [1] http://jakarta.apache.org/commons/releases/versioning.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r549278 - in /jakarta/commons/proper/math/trunk: src/java/org/apache/commons/math/special/ src/test/org/apache/commons/math/special/ xdocs/
Author: psteitz
Date: Wed Jun 20 15:24:04 2007
New Revision: 549278
URL: http://svn.apache.org/viewvc?view=revrev=549278
Log:
Increased default epsilon for Gamma, Beta function evaluation.
JIRA: MATH-166
Reported and patched by Lukas Theussl
Modified:
jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/special/Beta.java
jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/special/Gamma.java
jakarta/commons/proper/math/trunk/src/test/org/apache/commons/math/special/BetaTest.java
jakarta/commons/proper/math/trunk/src/test/org/apache/commons/math/special/GammaTest.java
jakarta/commons/proper/math/trunk/xdocs/changes.xml
Modified:
jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/special/Beta.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/special/Beta.java?view=diffrev=549278r1=549277r2=549278
==
---
jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/special/Beta.java
(original)
+++
jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/special/Beta.java
Wed Jun 20 15:24:04 2007
@@ -33,7 +33,7 @@
private static final long serialVersionUID = -3833485397404128220L;
/** Maximum allowed numerical error. */
-private static final double DEFAULT_EPSILON = 10e-9;
+private static final double DEFAULT_EPSILON = 10e-15;
/**
* Default constructor. Prohibit instantiation.
Modified:
jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/special/Gamma.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/special/Gamma.java?view=diffrev=549278r1=549277r2=549278
==
---
jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/special/Gamma.java
(original)
+++
jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/special/Gamma.java
Wed Jun 20 15:24:04 2007
@@ -34,7 +34,7 @@
private static final long serialVersionUID = -6587513359895466954L;
/** Maximum allowed numerical error. */
-private static final double DEFAULT_EPSILON = 10e-9;
+private static final double DEFAULT_EPSILON = 10e-15;
/** Lanczos coefficients */
private static double[] lanczos =
Modified:
jakarta/commons/proper/math/trunk/src/test/org/apache/commons/math/special/BetaTest.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/math/trunk/src/test/org/apache/commons/math/special/BetaTest.java?view=diffrev=549278r1=549277r2=549278
==
---
jakarta/commons/proper/math/trunk/src/test/org/apache/commons/math/special/BetaTest.java
(original)
+++
jakarta/commons/proper/math/trunk/src/test/org/apache/commons/math/special/BetaTest.java
Wed Jun 20 15:24:04 2007
@@ -38,7 +38,7 @@
{
try {
double actual = Beta.regularizedBeta(x, a, b);
-TestUtils.assertEquals(expected, actual, 10e-5);
+TestUtils.assertEquals(expected, actual, 10e-15);
} catch(MathException ex){
fail(ex.getMessage());
}
@@ -46,7 +46,7 @@
private void testLogBeta(double expected, double a, double b) {
double actual = Beta.logBeta(a, b);
-TestUtils.assertEquals(expected, actual, 10e-5);
+TestUtils.assertEquals(expected, actual, 10e-15);
}
public void testRegularizedBetaNanPositivePositive() {
@@ -114,6 +114,6 @@
}
public void testLogBetaPositivePositive() {
-testLogBeta(-0.693147, 1.0, 2.0);
+testLogBeta(-0.693147180559945, 1.0, 2.0);
}
}
Modified:
jakarta/commons/proper/math/trunk/src/test/org/apache/commons/math/special/GammaTest.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/math/trunk/src/test/org/apache/commons/math/special/GammaTest.java?view=diffrev=549278r1=549277r2=549278
==
---
jakarta/commons/proper/math/trunk/src/test/org/apache/commons/math/special/GammaTest.java
(original)
+++
jakarta/commons/proper/math/trunk/src/test/org/apache/commons/math/special/GammaTest.java
Wed Jun 20 15:24:04 2007
@@ -37,8 +37,8 @@
try {
double actualP = Gamma.regularizedGammaP(a, x);
double actualQ = Gamma.regularizedGammaQ(a, x);
-TestUtils.assertEquals(expected, actualP, 10e-5);
-TestUtils.assertEquals(actualP, 1.0 - actualQ, 10e-5);
+TestUtils.assertEquals(expected, actualP, 10e-15);
+TestUtils.assertEquals(actualP, 1.0 - actualQ, 10e-15);
} catch(MathException ex){
fail(ex.getMessage());
}
@@ -46,7 +46,7 @@
private void testLogGamma(double expected, double x) {
double actual =
[jira] Resolved: (MATH-166) Special functions not very accurate
[ https://issues.apache.org/jira/browse/MATH-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz resolved MATH-166. -- Resolution: Fixed Patch applied. Thanks Special functions not very accurate --- Key: MATH-166 URL: https://issues.apache.org/jira/browse/MATH-166 Project: Commons Math Issue Type: Bug Affects Versions: 1.1 Reporter: Lukas Theussl Priority: Minor Fix For: 1.2 Attachments: MATH-166.patch The Gamma and Beta functions return values in double precision but the default epsilon is set to 10e-9. I think that the default should be set to the highest possible accuracy, as this is what I'd expect to be returned by a double precision routine. Note that the erf function already uses a call to Gamma.regularizedGammaP with an epsilon of 1.0e-15. -- 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]
Commons is TLP
Hi everyone, The new Commons TLP was established today, with Torsten Curdt as Vice President. Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] 3rd attempt: Release commons-io 1.3.2
On 6/20/07, Jochen Wiedmann [EMAIL PROTECTED] wrote: On 6/20/07, Phil Steitz [EMAIL PROTECTED] wrote: It is up to the RM, but with a -1 from a major contributor to the code base, I would personally not push out the release. FWIW, as mentioned on other threads, I agree with Stephen on the version number issue. The problem is simply that votes for releases on commons drive me sick. It is not the exception, but the standard, that people demand changes (which they of course assume that the RM will do) and use a -1 to enforce their opinion. I have a different opinion in this matter. I see absolutely no problem with a compiler warning as long as I may drop in the binary to a running system: *That* is what I call binary compatible and what assume to be the contract for binary releases. My point of view is that he or she who demands such work (going through the docs and find all occurrencies of 1.3.2 and such is a nontrivial work and will easily take two hours or so) should be ready to do it for himself *or* leave it up to me to decide. My 2 cents... Commons operates in a slightly different way than most projects. On other projects the group of developers have a shared goal on the code they develop and release. Here at commons we have a set of components that on their own probably couldn't muster enough community to pass a release vote and rely on the goodwill of other developers (that probably have no interest in the component) to check out the RC and vote. Speaking for myself I have always appreciated people taking the time to help me get releases out and - since I don't think I can take it for granted - always tried to resolve the issues people have raised. As an eco-system this seems to work for small components with few developers. If we start to react to people reviewing as being a PITA or ignoring comments - then one likely reaction is for people to stop doing reviews (and casting a vote) - then our eco-system starts to break down. On the actual issue - I don't have a problem with deprecating in a minor version (IMO the real issue is at what point deprecated code can be removed) - Stephen does though, but it is down to you(the RM) whether you chose to keep him happy or release as it is. Niall Jochen -- Besides, manipulating elections is under penalty of law, resulting in a preventative effect against manipulating elections. The german government justifying the use of electronic voting machines and obviously believing that we don't need a police, because all illegal actions are forbidden. http://dip.bundestag.de/btd/16/051/1605194.pdf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r549299 - in /jakarta/commons/proper/math/trunk: src/java/org/apache/commons/math/util/MathUtils.java src/test/org/apache/commons/math/util/MathUtilsTest.java xdocs/changes.xml
Author: psteitz
Date: Wed Jun 20 16:39:50 2007
New Revision: 549299
URL: http://svn.apache.org/viewvc?view=revrev=549299
Log:
Added log function.
JIRA: MATH-158
Modified:
jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/util/MathUtils.java
jakarta/commons/proper/math/trunk/src/test/org/apache/commons/math/util/MathUtilsTest.java
jakarta/commons/proper/math/trunk/xdocs/changes.xml
Modified:
jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/util/MathUtils.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/util/MathUtils.java?view=diffrev=549299r1=549298r2=549299
==
---
jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/util/MathUtils.java
(original)
+++
jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/util/MathUtils.java
Wed Jun 20 16:39:50 2007
@@ -117,7 +117,26 @@
}
return result;
}
-
+
+/**
+ * pReturns the
+ * a href=http://mathworld.wolfram.com/Logarithm.html;logarithm/a
+ * for base codeb/code of codex/code.
+ * /p
+ * pReturns codeNaNcode if either argument is negative. If
+ * codebase/code is 0 and codex/code is positive, 0 is returned.
+ * If codebase/code is positive and codex/code is 0,
+ * codeDouble.NEGATIVE_INFINITY/code is returned. If both arguments
+ * are 0, the result is codeNaN/code./p
+ *
+ * @param base the base of the logarithm, must be greater than 0
+ * @param x argument, must be greater than 0
+ * @return the value of the logarithm - the number y such that base^y = x.
+ */
+public static double log(double base, double x) {
+ return Math.log(x)/Math.log(base);
+}
+
/**
* Returns a codedouble/code representation of the a
* href=http://mathworld.wolfram.com/BinomialCoefficient.html; Binomial
Modified:
jakarta/commons/proper/math/trunk/src/test/org/apache/commons/math/util/MathUtilsTest.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/math/trunk/src/test/org/apache/commons/math/util/MathUtilsTest.java?view=diffrev=549299r1=549298r2=549299
==
---
jakarta/commons/proper/math/trunk/src/test/org/apache/commons/math/util/MathUtilsTest.java
(original)
+++
jakarta/commons/proper/math/trunk/src/test/org/apache/commons/math/util/MathUtilsTest.java
Wed Jun 20 16:39:50 2007
@@ -444,6 +444,16 @@
}
}
+public void testLog() {
+ assertEquals(2.0, MathUtils.log(2,4), 0);
+ assertEquals(3.0, MathUtils.log(2,8), 0);
+assertTrue(Double.isNaN(MathUtils.log(-1, 1)));
+assertTrue(Double.isNaN(MathUtils.log(1, -1)));
+assertTrue(Double.isNaN(MathUtils.log(0, 0)));
+assertEquals(0, MathUtils.log(0, 10), 0);
+assertEquals(Double.NEGATIVE_INFINITY, MathUtils.log(10, 0), 0);
+}
+
public void testGcd() {
int a = 30;
int b = 50;
Modified: jakarta/commons/proper/math/trunk/xdocs/changes.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/math/trunk/xdocs/changes.xml?view=diffrev=549299r1=549298r2=549299
==
--- jakarta/commons/proper/math/trunk/xdocs/changes.xml (original)
+++ jakarta/commons/proper/math/trunk/xdocs/changes.xml Wed Jun 20 16:39:50 2007
@@ -81,6 +81,9 @@
action dev=psteitz type=fix issue=MATH-166 due-to=Lukas Theussl
Increased default precision of Gamma and Beta functions.
/action
+ action dev=psteitz type=update issue=MATH-158 due-to Hasan
Diwan
+Added log function to MathUtils.
+ /action
/release
release version=1.1 date=2005-12-17
description=This is a maintenance release containing bug fixes and
enhancements.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (MATH-158) Arbitrary log
[ https://issues.apache.org/jira/browse/MATH-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz resolved MATH-158. -- Resolution: Fixed Modified version of patch applied. Changes: made arguments doubles and used conventional names for base, argument. Also documented behavior for 0, negative arguments. Thanks! Arbitrary log - Key: MATH-158 URL: https://issues.apache.org/jira/browse/MATH-158 Project: Commons Math Issue Type: New Feature Reporter: Hasan Diwan Priority: Minor Fix For: 1.2 Attachments: commons-math.pat Patch adds the change-of-base property for a logarithm and a test to make sure it works. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LANG-333) ArrayUtils.toClass
[ https://issues.apache.org/jira/browse/LANG-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Meikle updated LANG-333: - Attachment: LANG-333.patch Patch to Implement ArrayUtils.toClass() and Unit Test ArrayUtils.toClass -- Key: LANG-333 URL: https://issues.apache.org/jira/browse/LANG-333 Project: Commons Lang Issue Type: Improvement Reporter: Jörg Gottschling Fix For: 3.0 Attachments: LANG-333.patch ArrayUtils should have a Method toClass(array : Object[]) : Class[] which creates a new Array with the Class-Objects of the Objects in the Array. Very nice for Reflection. -- 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] RE: [EMAIL PROTECTED]: Project ivy (in module ivy) failed
Hi Gilles! I traced back the failure in the gump build of ivy up to [1]. A class that we use in VFS has been renamed. I guess you mean the ThreadLocalHttpConnectionManager class (former WebdavConnectionManager). May I ask, why you use it directly? 3. Replace our dependency to commons-vfs-sandbox in gump by a static dependency version. 4. Copy the old WebdavConnectionManager to the ivy codebase until vfs 1.1 has been released. Btw, I am trying to upgrade the httpclient library to 3.0.1 which also involves some changes on the ConnectionManager stuff, so we might run into troubles again. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
