[Re:] connect to ftp server via proxy..
I will be in touch with you around that time. I'll wait until this time Rory :) Bye. -- The whole purpose of places like Starbucks is for people with no decision-making ability whatsoever to make six decisions just to buy one cup of coffee. Short, tall, light, dark, caf, decaf, low-fat, non-fat, etc. So people who don't know what the hell they're doing or who on earth they are can, for only $2.95, get not just a cup of coffee but an absolutely defining sense of self: Tall. Decaf. Cappuccino. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-jelly-tags-jsl-test (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-jsl-test has an issue affecting its community integration. This issue affects 1 projects. 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-20082006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-20082006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-20082006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-20082006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-20082006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-20082006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-20082006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-20082006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-20082006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-20082006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-20082006.jar - [junit] at org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:63) [junit] at org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:58) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:65) [junit] at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:112) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:160) [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) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:91) [junit] at
[EMAIL PROTECTED]: Project commons-jelly-tags-jsl-test (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-jsl-test has an issue affecting its community integration. This issue affects 1 projects. 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-20082006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-20082006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-20082006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-20082006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-20082006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-20082006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-20082006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-20082006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-20082006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-20082006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-20082006.jar - [junit] at org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:63) [junit] at org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:58) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:65) [junit] at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:112) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:160) [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) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:91) [junit] at
[Collections] SynchronizedCollection should check for null Locks.
Hello list,
In my opinion it would be good if SynchronizedCollection checked in its
protected Constructor which takes a collection and a lock, if the lock
were actually null (as advertised in the javadoc).
I have added a unidiff (Against collections-3.2) to address this issue
Robert Ribnitz
---
../commons-collections-3.2-src-orig/./src/java/org/apache/commons/collections/collection/SynchronizedCollection.java
2006-05-14 22:39:40.0 +0200
+++
./src/java/org/apache/commons/collections/collection/SynchronizedCollection.java
2006-08-20 14:45:17.574110536 +0200
@@ -79,12 +79,16 @@
*
* @param collection the collection to decorate, must not be null
* @param lock the lock object to use, must not be null
- * @throws IllegalArgumentException if the collection is null
+ * @throws IllegalArgumentException if either the collection or
+ * the lock are null
*/
protected SynchronizedCollection(Collection collection, Object lock) {
if (collection == null) {
throw new IllegalArgumentException(Collection must not be null);
}
+if (lock == null) {
+ throw new IllegalArgumentException(Lock must not be null);
+}
this.collection = collection;
this.lock = lock;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r432981 - /jakarta/commons/proper/dbcp/trunk/xdocs/configuration.xml
Author: psteitz Date: Sun Aug 20 08:54:03 2006 New Revision: 432981 URL: http://svn.apache.org/viewvc?rev=432981view=rev Log: Fixed errors in pool parameter documentation and made 0 value for _maxPreparedStatements in DriverAdapterCPDS behave like a negative value, to be consistent with documentation and pool behavior. Jira: DBCP-41 Patch due to: Anton Tagunov Modified: jakarta/commons/proper/dbcp/trunk/xdocs/configuration.xml Modified: jakarta/commons/proper/dbcp/trunk/xdocs/configuration.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/dbcp/trunk/xdocs/configuration.xml?rev=432981r1=432980r2=432981view=diff == --- jakarta/commons/proper/dbcp/trunk/xdocs/configuration.xml (original) +++ jakarta/commons/proper/dbcp/trunk/xdocs/configuration.xml Sun Aug 20 08:54:03 2006 @@ -137,7 +137,7 @@ tdmaxIdle/td td8/td td - The maximum number of active connections that can remain idle in the + The maximum number of connections that can remain idle in the pool, without extra ones being released, or negative for no limit. /td /tr @@ -145,7 +145,7 @@ tdminIdle/td td0/td td - The minimum number of active connections that can remain idle in the + The minimum number of connections that can remain idle in the pool, without extra ones being created, or zero to create none. /td /tr - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r432981 - /jakarta/commons/proper/dbcp/trunk/xdocs/configuration.xml
Aaargh! Pushed wrong log. Should read: Removed incorrect reference to active connections in documentation for maxIdle, minIdle Jira: DBCP-197 Patch due to: Michael Heuer Have to figure out how to get log fixed in svn... Phil On 8/20/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: psteitz Date: Sun Aug 20 08:54:03 2006 New Revision: 432981 URL: http://svn.apache.org/viewvc?rev=432981view=rev Log: Fixed errors in pool parameter documentation and made 0 value for _maxPreparedStatements in DriverAdapterCPDS behave like a negative value, to be consistent with documentation and pool behavior. Jira: DBCP-41 Patch due to: Anton Tagunov Modified: jakarta/commons/proper/dbcp/trunk/xdocs/configuration.xml Modified: jakarta/commons/proper/dbcp/trunk/xdocs/configuration.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/dbcp/trunk/xdocs/configuration.xml?rev=432981r1=432980r2=432981view=diff == --- jakarta/commons/proper/dbcp/trunk/xdocs/configuration.xml (original) +++ jakarta/commons/proper/dbcp/trunk/xdocs/configuration.xml Sun Aug 20 08:54:03 2006 @@ -137,7 +137,7 @@ tdmaxIdle/td td8/td td - The maximum number of active connections that can remain idle in the + The maximum number of connections that can remain idle in the pool, without extra ones being released, or negative for no limit. /td /tr @@ -145,7 +145,7 @@ tdminIdle/td td0/td td - The minimum number of active connections that can remain idle in the + The minimum number of connections that can remain idle in the pool, without extra ones being created, or zero to create none. /td /tr - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (DBCP-197) Incorrect parameter descriptions for maxIdle and minIdle, at http://jakarta.apache.org/commons/dbcp/configuration.html
[ http://issues.apache.org/jira/browse/DBCP-197?page=all ] Phil Steitz updated DBCP-197: - Fix Version/s: 1.2.2 Incorrect parameter descriptions for maxIdle and minIdle, at http://jakarta.apache.org/commons/dbcp/configuration.html -- Key: DBCP-197 URL: http://issues.apache.org/jira/browse/DBCP-197 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.2.1 Reporter: Michael Heuer Priority: Minor Fix For: 1.2.2 Attachments: diff.txt The parameter descriptions for maxIdle and minIdle incorrectly refer to active connections: Parameter Default Description initialSize 0 The initial number of connections that are created when the pool is started. maxActive 8 The maximum number of active connections that can be allocated from this pool at the same time, or negative for no limit. maxIdle 8 The maximum number of active connections that can remain idle in the pool, without extra ones being released, or zero for no limit. minIdle 0 The minimum number of active connections that can remain idle in the pool, without extra ones being created, or zero to create none. A connection cannot be both active and idle by definition. svn diff attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (DBCP-197) Incorrect parameter descriptions for maxIdle and minIdle, at http://jakarta.apache.org/commons/dbcp/configuration.html
[ http://issues.apache.org/jira/browse/DBCP-197?page=all ] Phil Steitz resolved DBCP-197. -- Resolution: Fixed Patch applied. Thanks! Incorrect parameter descriptions for maxIdle and minIdle, at http://jakarta.apache.org/commons/dbcp/configuration.html -- Key: DBCP-197 URL: http://issues.apache.org/jira/browse/DBCP-197 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.2.1 Reporter: Michael Heuer Priority: Minor Fix For: 1.2.2 Attachments: diff.txt The parameter descriptions for maxIdle and minIdle incorrectly refer to active connections: Parameter Default Description initialSize 0 The initial number of connections that are created when the pool is started. maxActive 8 The maximum number of active connections that can be allocated from this pool at the same time, or negative for no limit. maxIdle 8 The maximum number of active connections that can remain idle in the pool, without extra ones being released, or zero for no limit. minIdle 0 The minimum number of active connections that can remain idle in the pool, without extra ones being created, or zero to create none. A connection cannot be both active and idle by definition. svn diff attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] maven group ids
Tomasz Pik wrote: On 8/16/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Yes, but instead of transiting something, that depends on other commons IMHO something without dependencies should be transited first. In other words, first thing to be done should be a graph of dependencies between various commons packages and those without dependencies should be migrated first. I guess commons-lang is a good candidate here, not configuration that depdends on many other (not migrated yet) components. What would we gain from this? A transition of component A will not include updating existing commons-dependencies in component A to the new ones with the new groupId. That will require a new release of that component A. If fact we don't even have to wait for a release of a component to do this. There is a good reason for *not* picking commons-lang or commons-logging, two components without dependencies on other commons components, as the first component to transition. That is that both are on ibiblio's top 10 downloads list. I had link to it before but can't seem to find it now, sorry. If we do it wrong there then all hell will break loose. It'd be better to choose a medium used component. But this means, that all of those users, that downloading those top10 jars in near future will have obosolete jars. They are *not* obsolete. They are relocated. They still function in exactly the same way as before. The only difference is that there is a relocation section in the pom that indicates to Maven 2 that this project has changed one or more of groupId, artifactId or version. Maven is not re-downloading nonSNAPSHOT artifacts so... Let's imagine I'm a new maven user having project with a dependency on commons-lang:commons-lang-2.1 and maven will download it for me. Some time later this package will be relocated to org.apache.commons.lang:commons-lang:2.1 (or similar). After that there'll be new, let's say acegi v1.4 depending on this 'new' commons-lang (org.apache:commons-lang:2.1) and I need this acegi in my project. So after adding dependency on acegi maven will download org.apache.commons.lang:commons-lang:2.1 and won't download commons-lang:commons-lang:2.1 (which should result as relocation info) and finally, maven will be adding those two commons-lang jars into classpath, copy into WEB-INF/lib and so on. This was one of the tests that I performed when testing this. It is a problem only for Maven 1 which does not handle relocations at all. In Maven 2 this is handled transparently and you will not get two jars in your WEB-INF/lib, only one. All of this till the time I'll manually remove commons-lang:commons-lang:2.1 from my repository so maven will be forced to reload them (and will download relocation info then). It is true that Maven 2 does not re-download something once it has successfully downloaded it, but that has no impact on this discussion. So finally I think that sooner those jars will be relocated there'll be less users having problems like this. As I said before I'm all for a quick transition, but since commons components are very widely used, we have to make sure that we do everything correctly. Regards, Tomek -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r432981 - /jakarta/commons/proper/dbcp/trunk/xdocs/configuration.xml
On 8/20/06, Phil Steitz [EMAIL PROTECTED] wrote: Aaargh! Pushed wrong log. Should read: Removed incorrect reference to active connections in documentation for maxIdle, minIdle Jira: DBCP-197 Patch due to: Michael Heuer Have to figure out how to get log fixed in svn... snip/ http://subversion.tigris.org/faq.html#change-log-msg -Rahul Phil On 8/20/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: psteitz Date: Sun Aug 20 08:54:03 2006 New Revision: 432981 URL: http://svn.apache.org/viewvc?rev=432981view=rev Log: Fixed errors in pool parameter documentation and made 0 value for _maxPreparedStatements in DriverAdapterCPDS behave like a negative value, to be consistent with documentation and pool behavior. Jira: DBCP-41 Patch due to: Anton Tagunov snap/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] maven group ids
Oliver Heger wrote: Dennis Lundberg wrote: snip/ I had a look at the Apache Maven 1 repo at http://people.apache.org/repo/m1-ibiblio-rsync-repository/ There doesn't seem to be any consistency when looking at different components. I had a look at a few: configuration: - older jars have md5 - newer jars have md5 and asc - older poms have no md5 or asc - newer poms have md5 lang: - jars have md5 - poms have md5 logging: - older jars have md5 - newer jars have md5 and asc - older poms have md5 - newer poms have md5 and asc snip/ Section 8 of the Commons releasing components guide [1] demands that all files placed in the ASF Java Respository need to be signed. I think that this part is relative new, which explains why newer poms are signed while older ones are not. Thanks for that pointer Oliver. I guess this section is to comply with the ASF release signing policy. I still think that we should sign the poms (with the relocation element added) only if they were signed when they were released. By the way the Jakarta document needs to be updated as the java-repository has moved on people.o.a. I will try to patch that. Oliver [1] http://jakarta.apache.org/commons/releases/release.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] maven group ids
On 8/20/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Tomasz Pik wrote: On 8/16/06, Dennis Lundberg [EMAIL PROTECTED] wrote: Yes, but instead of transiting something, that depends on other commons IMHO something without dependencies should be transited first. In other words, first thing to be done should be a graph of dependencies between various commons packages and those without dependencies should be migrated first. I guess commons-lang is a good candidate here, not configuration that depdends on many other (not migrated yet) components. What would we gain from this? A transition of component A will not include updating existing commons-dependencies in component A to the new ones with the new groupId. That will require a new release of that component A. If fact we don't even have to wait for a release of a component to do this. There is a good reason for *not* picking commons-lang or commons-logging, two components without dependencies on other commons components, as the first component to transition. That is that both are on ibiblio's top 10 downloads list. I had link to it before but can't seem to find it now, sorry. If we do it wrong there then all hell will break loose. It'd be better to choose a medium used component. But this means, that all of those users, that downloading those top10 jars in near future will have obosolete jars. They are *not* obsolete. They are relocated. They still function in exactly the same way as before. The only difference is that there is a relocation section in the pom that indicates to Maven 2 that this project has changed one or more of groupId, artifactId or version. Maven is not re-downloading nonSNAPSHOT artifacts so... Let's imagine I'm a new maven user having project with a dependency on commons-lang:commons-lang-2.1 and maven will download it for me. Some time later this package will be relocated to org.apache.commons.lang:commons-lang:2.1 (or similar). After that there'll be new, let's say acegi v1.4 depending on this 'new' commons-lang (org.apache:commons-lang:2.1) and I need this acegi in my project. So after adding dependency on acegi maven will download org.apache.commons.lang:commons-lang:2.1 and won't download commons-lang:commons-lang:2.1 (which should result as relocation info) and finally, maven will be adding those two commons-lang jars into classpath, copy into WEB-INF/lib and so on. This was one of the tests that I performed when testing this. It is a problem only for Maven 1 which does not handle relocations at all. In Maven 2 this is handled transparently and you will not get two jars in your WEB-INF/lib, only one. All of this till the time I'll manually remove commons-lang:commons-lang:2.1 from my repository so maven will be forced to reload them (and will download relocation info then). It is true that Maven 2 does not re-download something once it has successfully downloaded it, but that has no impact on this discussion. It has some impact for final users... Maven won't 'redownload' commons-lang:commons-lang:2.1 and if threre'll be something that depends on org.apache.commons:commons-lang:2.2. Maven won't know that it's only a version difference, for Maven those components are a completly different packages so both will be added to classpath, packaged into wars and so on. And for example for most servlet containers I've observed, that they added jars in alphabetized order, so commons-lang:2.1 will 'win'. So finally I think that sooner those jars will be relocated there'll be less users having problems like this. As I said before I'm all for a quick transition, but since commons components are very widely used, we have to make sure that we do everything correctly. 100% agree :) Regards, Tomek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[beanutils] Webapp using commons-logging fails to start in Tomcat 4.1.x when beanutils 1.7.0 is used by Tomcat
Hi, The most recent Tomcat 4 release upgraded from beanutils 1.6.1 to 1.7.0 and this introduced a conflict with commons-logging (see http://issues.apache.org/bugzilla/show_bug.cgi?id=40252). As the issues boils down to fun and games with containers and classloader hierarchies, this might not be a beanutils issue at all but given the issue became apparent after a change in beanutils this seems like the right place to start. Since this discussion revolves around changes in the beanutils code, I am posting this to the dev list. If it is felt the users list is more appropriate, I am happy to move this thread to that list instead. With beanutils 1.6.1 utility classes such as BeanUtils and ConvertUtils were static and hence the associated Log instances were also static. All these objects were created by the Tomcat common classloader and all was well. In beanutils 1.7.0 the BeanUtilsBean class was introduced as per-context-classloader pseudo singletons. Providing commons-logging is not present in the webapp classloader then all is well. As soon as commons-logging is present in the webapp classloader, when the per context classloader instance of ConvertUtilsBean creates a logger it uses the Log class from the webapp classloader which conflicts with that in the common classloader and Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed. results. The only option for the webapp developer is not to include commons-logging but this does make for portable webapps - not all containers use commons-logging internally and a webapp may require this library. For now, my short-term solution is to revert to beanutils 1.6.1 for a TC4.1.33 release. Longer term, I wonder if the same sort of trick the OP for the above bug uses in webapps (see http://rbodkin.blogs.com/ron_bodkins_blog/2006/07/stupid_log_tric.html) could be used in beanutils. I would be happy to work on a patch in this direction if it was thought to be useful. However, I would value the insight of those more familiar with the beanutils code before starting since I don't want to waste time on a pointless exercise. Regards, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r432981 - /jakarta/commons/proper/dbcp/trunk/xdocs/configuration.xml
Thanks, Rahul! Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r433104 - in /jakarta/commons/proper/dbcp/trunk: src/java/org/apache/commons/dbcp/datasources/SharedPoolDataSource.java xdocs/changes.xml
Author: psteitz
Date: Sun Aug 20 17:35:13 2006
New Revision: 433104
URL: http://svn.apache.org/viewvc?rev=433104view=rev
Log:
Made userKeys an instance variable (i.e., not static) in SharedPoolDataSource.
Jira: DBCP-100
Modified:
jakarta/commons/proper/dbcp/trunk/src/java/org/apache/commons/dbcp/datasources/SharedPoolDataSource.java
jakarta/commons/proper/dbcp/trunk/xdocs/changes.xml
Modified:
jakarta/commons/proper/dbcp/trunk/src/java/org/apache/commons/dbcp/datasources/SharedPoolDataSource.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/dbcp/trunk/src/java/org/apache/commons/dbcp/datasources/SharedPoolDataSource.java?rev=433104r1=433103r2=433104view=diff
==
---
jakarta/commons/proper/dbcp/trunk/src/java/org/apache/commons/dbcp/datasources/SharedPoolDataSource.java
(original)
+++
jakarta/commons/proper/dbcp/trunk/src/java/org/apache/commons/dbcp/datasources/SharedPoolDataSource.java
Sun Aug 20 17:35:13 2006
@@ -45,7 +45,7 @@
public class SharedPoolDataSource
extends InstanceKeyDataSource {
-private static final Map userKeys = new LRUMap(10);
+private final Map userKeys = new LRUMap(10);
private int maxActive = GenericObjectPool.DEFAULT_MAX_ACTIVE;
private int maxIdle = GenericObjectPool.DEFAULT_MAX_IDLE;
Modified: jakarta/commons/proper/dbcp/trunk/xdocs/changes.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/dbcp/trunk/xdocs/changes.xml?rev=433104r1=433103r2=433104view=diff
==
--- jakarta/commons/proper/dbcp/trunk/xdocs/changes.xml (original)
+++ jakarta/commons/proper/dbcp/trunk/xdocs/changes.xml Sun Aug 20 17:35:13 2006
@@ -130,6 +130,10 @@
like a negative value, to be consistent with documentation
and pool behavior.
/action
+ action dev=psteitz type=fix issue=DBCP-100
+Made userKeys an instance variable (i.e., not static)
+in SharedPoolDataSource.
+ /action
/release
release version=1.2.1 date=2004-06-12 description=Maintenance
Release to restore JDK 1.3 compatibility
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (DBCP-100) [dbcp] NullPointerException retrieving connection from the pool
[ http://issues.apache.org/jira/browse/DBCP-100?page=all ] Phil Steitz resolved DBCP-100. -- Resolution: Fixed Made userKeys an instance variable. Fixed in r433104, nightlies starting 21-aug-06. [dbcp] NullPointerException retrieving connection from the pool --- Key: DBCP-100 URL: http://issues.apache.org/jira/browse/DBCP-100 Project: Commons Dbcp Issue Type: Bug Environment: Operating System: Windows XP Platform: Other Reporter: Fedor Karpelevitch Fix For: 1.2.2 under some load we start getting this exception when retrieving connection from pool: org.apache.commons.dbcp.SQLNestedException: Could not retrieve connection info from pool at org.apache.commons.dbcp.datasources.SharedPoolDataSource.getPooledConnectionAndInfo(SharedPoolDataSource.java:169) at org.apache.commons.dbcp.datasources.InstanceKeyDataSource.getConnection(InstanceKeyDataSource.java:631) at org.apache.commons.dbcp.datasources.InstanceKeyDataSource.getConnection(InstanceKeyDataSource.java:615) at org.apache.torque.TorqueInstance.getConnection(TorqueInstance.java:705) ... 34 more Caused by: java.lang.NullPointerException at org.apache.commons.collections.SequencedHashMap.insertEntry(SequencedHashMap.java:226) at org.apache.commons.collections.SequencedHashMap.put(SequencedHashMap.java:451) at org.apache.commons.collections.LRUMap.put(LRUMap.java:125) at org.apache.commons.dbcp.datasources.SharedPoolDataSource.getUserPassKey(SharedPoolDataSource.java:179) at org.apache.commons.dbcp.datasources.SharedPoolDataSource.getPooledConnectionAndInfo(SharedPoolDataSource.java:165) ... 37 more this is apparently caused by improper syncronization: SharedPoolDataSource.getPooledConnectionAndInfo() is synchronized _instance_ method, but it accesses SharedPoolDataSource.userKeys which is a _static_ variable, so if you have more than one instance of SharedPoolDataSource (as we do) access to the map would not be properly synchronized. So either map should be made instance variable, or the method should be synchronized on the class, not instance. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (DBCP-198) PoolingDataSource.PoolGuardConnectionWrapper equals() implementation incorrect
[ http://issues.apache.org/jira/browse/DBCP-198?page=all ]
Phil Steitz updated DBCP-198:
-
Fix Version/s: 1.2.2
PoolingDataSource.PoolGuardConnectionWrapper equals() implementation incorrect
--
Key: DBCP-198
URL: http://issues.apache.org/jira/browse/DBCP-198
Project: Commons Dbcp
Issue Type: Bug
Affects Versions: 1.2.1
Reporter: Kevin Ruland
Fix For: 1.2.2
The Object.equals( Object ) implementation in
PoolingDataSource.PoolGuardConnectionWrapper is broken because it does not
attempt to test if the outermost objects are equal. It should be replaced
with something like:
public boolean equals(Object obj) {
if ( obj == this ) return true;
if ( obj instanceof PoolGuardConnectionWrapper ) {
return delegate.equals( ((PoolGuardConnectionWrapper) obj).delegate );
return false;
}
The current implementation prevents putting PoolGuardConenctionWrapper
objects in Collections and using the standard contains( Object ) or remove(
Object ) methods.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[collections] binary search removeAll/retainAll + other convenience methods
Hi, I have written a few methods in recent months that may fit with [collections]. I'll do a copy/paste of the signatures + javadoc descriptions. Let me know what you think. (Apologies if any of this functionality already exists in [collections]. I took a quick look but didn't see any duplication.) 1) void removeAllUsingBinarySearch(List list1, List list2) 2) void retainAllUsingBinarySearch(List list1, List list2) Functionally the same as List.removeAll(Collection) and List.retainAll(Collection), but uses a binary search in order to find the matches (as opposed to the linear search in Sun's default implementation). (I was working with collections around 50,000 in size, and this made a very significant performance difference.) 3) List splitByMaximum(List items, int maxSize) Splits a list into sublists. Note that this method makes use of java.util.List.subList(int fromIndex, int toIndex), so the result lists are backed by the original -- changes to the result lists affect the original list. (I was in a situation where I had a large number of operations to perform, but due to memory constraints I had to limit the number of operations per transaction. This did the trick.) 4) Map subMap(Map map, List keys) Creates a subset of a map, containing only the specified keys. 5) List getMapValues(Map map, List keys) Using the provided map, gets the values for the specified keys. cheers, matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
