svn commit: r498105 - /jakarta/commons/proper/beanutils/trunk/optional/bean-collections/src/java/org/apache/commons/beanutils/BeanComparator.java
Author: niallp
Date: Sat Jan 20 03:50:37 2007
New Revision: 498105
URL: http://svn.apache.org/viewvc?view=revrev=498105
Log:
BEANUTILS-267 - BeanComparator constructor should check the comparator for
null and default to ComparableComparator - thanks to Jacob Kjome
Modified:
jakarta/commons/proper/beanutils/trunk/optional/bean-collections/src/java/org/apache/commons/beanutils/BeanComparator.java
Modified:
jakarta/commons/proper/beanutils/trunk/optional/bean-collections/src/java/org/apache/commons/beanutils/BeanComparator.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/beanutils/trunk/optional/bean-collections/src/java/org/apache/commons/beanutils/BeanComparator.java?view=diffrev=498105r1=498104r2=498105
==
---
jakarta/commons/proper/beanutils/trunk/optional/bean-collections/src/java/org/apache/commons/beanutils/BeanComparator.java
(original)
+++
jakarta/commons/proper/beanutils/trunk/optional/bean-collections/src/java/org/apache/commons/beanutils/BeanComparator.java
Sat Jan 20 03:50:37 2007
@@ -100,7 +100,11 @@
*/
public BeanComparator( String property, Comparator comparator ) {
setProperty( property );
-this.comparator = comparator;
+if (comparator != null) {
+this.comparator = comparator;
+} else {
+this.comparator = ComparableComparator.getInstance();
+}
}
/**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (BEANUTILS-267) BeanComparator(String, Comparator) should check the comparator for null and default to ComparableComparator.getInstance()
[
https://issues.apache.org/jira/browse/BEANUTILS-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton resolved BEANUTILS-267.
---
Resolution: Fixed
Fix Version/s: 1.8.0
Assignee: Niall Pemberton
Fixed, thanks for the suggestion:
http://svn.apache.org/viewvc?view=revrevision=498105
BeanComparator(String, Comparator) should check the comparator for null and
default to ComparableComparator.getInstance()
-
Key: BEANUTILS-267
URL: https://issues.apache.org/jira/browse/BEANUTILS-267
Project: Commons BeanUtils
Issue Type: Improvement
Components: Bean-Collections
Affects Versions: 1.7.0
Reporter: Jacob Kjome
Assigned To: Niall Pemberton
Priority: Minor
Fix For: 1.8.0
The way the BeanComparator(String, Comparator) constructor is implemented is
inconvenient. I've got code that passes in a comparator. This comparator
may be null. I assumed that the 2-args constructor would sanely ignore a
null comparator argument and use a default like ReverseComparator does in
commons-collections, but alas, no. I have to do the null check before I pass
it in
For instance, here's the constructor for ReverseComparator, which takes a
Comparator argument...
public ReverseComparator(Comparator comparator) {
if(comparator != null) {
this.comparator = comparator;
} else {
this.comparator = ComparableComparator.getInstance();
}
}
The null check and provided default is convenient and reasonable.
Here's the current constructor for BeanComparator that can only end in a
NullPointerException if provided null comparator
public BeanComparator( String property, Comparator comparator ) {
setProperty( property );
this.comparator = comparator;
}
Why not?
public BeanComparator( String property, Comparator comparator ) {
setProperty( property );
if(comparator != null) {
this.comparator = comparator;
} else {
this.comparator = ComparableComparator.getInstance();
}
}
The fact that BeanComparator allows itself to be put in a bad state by
storing a null comparator which it later tries to use with no null check,
guaranteeing a NullPointerException, probably should be considered a bug.
However, since it works just fine when provided a non-null comparator, I
consider this more of an Improvement opportunity than a bug, thus the
reported Issue Type. Hopefully this can be applied to the next release.
Jake
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://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] Commented: (DAEMON-24) [daemon] jsvc assumes posix capabilities loaded
[ https://issues.apache.org/jira/browse/DAEMON-24?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466233 ] Simone Piunno commented on DAEMON-24: - On my system it doesn't work despite the capability module being loaded. [EMAIL PROTECTED] ~ $ uname -a Linux roentgen 2.6.19-gentoo-r4 #1 PREEMPT Sun Jan 14 13:01:55 CET 2007 x86_64 AMD Athlon(tm) 64 Processor 3200+ AuthenticAMD GNU/Linux [EMAIL PROTECTED] ~ $ lsmod|grep capa capability 4296 0 commoncap 5952 1 capability in the errfile I get: 14/01/2007 00:42:58 31709 jsvc.exec error: syscall failed in set_caps 14/01/2007 00:42:58 31709 jsvc.exec error: set_caps(CAPS) failed 14/01/2007 00:42:58 31708 jsvc.exec error: Service exit with a return value of 4 I'm attaching a patch [daemon] jsvc assumes posix capabilities loaded --- Key: DAEMON-24 URL: https://issues.apache.org/jira/browse/DAEMON-24 Project: Commons Daemon Issue Type: Bug Environment: Operating System: Linux Platform: PC Reporter: Michael Thome later versions of linux (e.g. 2.6.x) may have capability management configured as a module rather than compiled in. A LKML discussion is ongoing as to if this is a good idea or not, but the upshot is that jsvc will fail on capset if the kernel doesn't have the module loaded. I'd suggest a note in the release notes and/or linux faq section discussing the issue. I'd be happy to propose a doc patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://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: (DAEMON-24) [daemon] jsvc assumes posix capabilities loaded
[ https://issues.apache.org/jira/browse/DAEMON-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Piunno updated DAEMON-24: Attachment: 1.0.1-capabilities.patch [daemon] jsvc assumes posix capabilities loaded --- Key: DAEMON-24 URL: https://issues.apache.org/jira/browse/DAEMON-24 Project: Commons Daemon Issue Type: Bug Environment: Operating System: Linux Platform: PC Reporter: Michael Thome Attachments: 1.0.1-capabilities.patch later versions of linux (e.g. 2.6.x) may have capability management configured as a module rather than compiled in. A LKML discussion is ongoing as to if this is a good idea or not, but the upshot is that jsvc will fail on capset if the kernel doesn't have the module loaded. I'd suggest a note in the release notes and/or linux faq section discussing the issue. I'd be happy to propose a doc patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://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] Created: (DAEMON-92) jsvc fails to execve() self on Linux
jsvc fails to execve() self on Linux Key: DAEMON-92 URL: https://issues.apache.org/jira/browse/DAEMON-92 Project: Commons Daemon Issue Type: Bug Affects Versions: 1.0.1 Final Reporter: Simone Piunno Fix For: 1.0.1 Final On Linux jsvc execve() itself. execve() requires an absolute path as the first argument therefore use of argv[0] only works when jsvc was invoked with a full path. Executing jsvc as relative path fails with jsvc error: Cannot execute JSVC executor process. On Linux the full path to self is very easy to find: /proc/self/exe I'm attaching a patch fixing this problem and falling back to argv[0] in case /proc is not mounted. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://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: (DAEMON-92) jsvc fails to execve() self on Linux
[ https://issues.apache.org/jira/browse/DAEMON-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Piunno updated DAEMON-92: Attachment: 1.0.1-execve-self.patch jsvc fails to execve() self on Linux Key: DAEMON-92 URL: https://issues.apache.org/jira/browse/DAEMON-92 Project: Commons Daemon Issue Type: Bug Affects Versions: 1.0.1 Final Reporter: Simone Piunno Fix For: 1.0.1 Final Attachments: 1.0.1-execve-self.patch On Linux jsvc execve() itself. execve() requires an absolute path as the first argument therefore use of argv[0] only works when jsvc was invoked with a full path. Executing jsvc as relative path fails with jsvc error: Cannot execute JSVC executor process. On Linux the full path to self is very easy to find: /proc/self/exe I'm attaching a patch fixing this problem and falling back to argv[0] in case /proc is not mounted. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://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] Created: (DISCOVERY-10) Add jar target to commons-discovery build.xml
Add jar target to commons-discovery build.xml - Key: DISCOVERY-10 URL: https://issues.apache.org/jira/browse/DISCOVERY-10 Project: Commons Discovery Issue Type: Bug Affects Versions: 0.4 Reporter: Petteri Räty Priority: Minor Fix For: Nightly Builds I added the jar target so that you don't have to generate javadocs to be able to build the jar file. This is required to follow the Gentoo java packaging policy and is the most common build.xml target layout. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://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: (DISCOVERY-10) Add jar target to commons-discovery build.xml
[ https://issues.apache.org/jira/browse/DISCOVERY-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Petteri Räty updated DISCOVERY-10: -- Attachment: commons-discovery-jar-target.patch Add jar target to commons-discovery build.xml - Key: DISCOVERY-10 URL: https://issues.apache.org/jira/browse/DISCOVERY-10 Project: Commons Discovery Issue Type: Bug Affects Versions: 0.4 Reporter: Petteri Räty Priority: Minor Fix For: Nightly Builds Attachments: commons-discovery-jar-target.patch I added the jar target so that you don't have to generate javadocs to be able to build the jar file. This is required to follow the Gentoo java packaging policy and is the most common build.xml target layout. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://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] Created: (COLLECTIONS-240) MultiValueMap should implement Serializable
MultiValueMap should implement Serializable --- Key: COLLECTIONS-240 URL: https://issues.apache.org/jira/browse/COLLECTIONS-240 Project: Commons Collections Issue Type: Bug Components: Map Affects Versions: 3.2 Reporter: Wouter de Vaal Collection classes should be serializable as they are frequently used in model classes which need to be serializable, for example in a HttpSession object within a servlet container cluster. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://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]
[EMAIL PROTECTED]: Project commons-jelly-tags-soap (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-soap has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 58 runs. The current state of this project is 'Failed', with reason 'Configuration Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-soap : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-soap/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-soap-20012007.jar] identifier set to project name -ERROR- No such project [ws-jaxme] for property. -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme-api on: Maven on Project:commons-jelly-tags-soap -DEBUG- Dependency on ws-axis exists, no need to add for property maven.jar.axis. -DEBUG- Dependency on ws-axis exists, no need to add for property maven.jar.jaxrpc-api. -DEBUG- Dependency on ws-axis exists, no need to add for property maven.jar.saaj-api. -DEBUG- Dependency on jakarta-servletapi-5-servlet exists, no need to add for property maven.jar.servletapi. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -INFO- Failed with reason configuration failed -ERROR- Bad Dependency. Project: ws-jaxme unknown to *this* workspace -INFO- Failed to extract fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-soap/rss.xml - Atom: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-soap/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 1720012007, vmgump.apache.org:vmgump-public:1720012007 Gump E-mail Identifier (unique within run) #29. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-jelly-tags-soap (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-soap has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 58 runs. The current state of this project is 'Failed', with reason 'Configuration Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-soap : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-soap/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-soap-20012007.jar] identifier set to project name -ERROR- No such project [ws-jaxme] for property. -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme-api on: Maven on Project:commons-jelly-tags-soap -DEBUG- Dependency on ws-axis exists, no need to add for property maven.jar.axis. -DEBUG- Dependency on ws-axis exists, no need to add for property maven.jar.jaxrpc-api. -DEBUG- Dependency on ws-axis exists, no need to add for property maven.jar.saaj-api. -DEBUG- Dependency on jakarta-servletapi-5-servlet exists, no need to add for property maven.jar.servletapi. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -INFO- Failed with reason configuration failed -ERROR- Bad Dependency. Project: ws-jaxme unknown to *this* workspace -INFO- Failed to extract fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-soap/rss.xml - Atom: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-soap/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 1720012007, vmgump.apache.org:vmgump-public:1720012007 Gump E-mail Identifier (unique within run) #29. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[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 58 runs. The current state of this project is 'Failed', with reason 'Configuration 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-20012007.jar] identifier set to project name -ERROR- No such project [ws-jaxme] for property. -ERROR- No such project [ws-jaxme] for property. -ERROR- No such project [ws-jaxme] for property. -ERROR- No such project [ws-jaxme] for property. -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme-js on: Maven on Project:commons-jelly-tags-jaxme -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme on: Maven on Project:commons-jelly-tags-jaxme -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme-api on: Maven on Project:commons-jelly-tags-jaxme -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme-xs on: Maven on Project:commons-jelly-tags-jaxme -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -INFO- Failed with reason configuration failed -ERROR- Bad Dependency. Project: ws-jaxme unknown to *this* workspace -INFO- Failed to extract fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/rss.xml - Atom: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 1720012007, vmgump.apache.org:vmgump-public:1720012007 Gump E-mail Identifier (unique within run) #37. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[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 58 runs. The current state of this project is 'Failed', with reason 'Configuration 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-20012007.jar] identifier set to project name -ERROR- No such project [ws-jaxme] for property. -ERROR- No such project [ws-jaxme] for property. -ERROR- No such project [ws-jaxme] for property. -ERROR- No such project [ws-jaxme] for property. -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme-js on: Maven on Project:commons-jelly-tags-jaxme -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme on: Maven on Project:commons-jelly-tags-jaxme -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme-api on: Maven on Project:commons-jelly-tags-jaxme -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme] -ERROR- Unhandled Property: maven.jar.jaxme-xs on: Maven on Project:commons-jelly-tags-jaxme -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -INFO- Failed with reason configuration failed -ERROR- Bad Dependency. Project: ws-jaxme unknown to *this* workspace -INFO- Failed to extract fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/rss.xml - Atom: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 1720012007, vmgump.apache.org:vmgump-public:1720012007 Gump E-mail Identifier (unique within run) #37. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r498129 - /jakarta/commons/proper/configuration/trunk/xdocs/howto_configurationbuilder.xml
Author: oheger Date: Sat Jan 20 07:48:24 2007 New Revision: 498129 URL: http://svn.apache.org/viewvc?view=revrev=498129 Log: Updated user guide for DefaultConfigurationBuilder to cover the new forceReloadCheck property Modified: jakarta/commons/proper/configuration/trunk/xdocs/howto_configurationbuilder.xml Modified: jakarta/commons/proper/configuration/trunk/xdocs/howto_configurationbuilder.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/xdocs/howto_configurationbuilder.xml?view=diffrev=498129r1=498128r2=498129 == --- jakarta/commons/proper/configuration/trunk/xdocs/howto_configurationbuilder.xml (original) +++ jakarta/commons/proper/configuration/trunk/xdocs/howto_configurationbuilder.xml Sat Jan 20 07:48:24 2007 @@ -294,7 +294,7 @@ /p source![CDATA[ header -result delimiterParsingDisabled=true +result delimiterParsingDisabled=true forceReloadCheck=true nodeCombiner config-class=org.apache.commons.configuration.tree.OverrideCombiner/ expressionEngine config-class=org.apache.commons.configuration.tree.xpath.XPathExpressionEngine/ /result @@ -315,7 +315,7 @@ ]]/source p The coderesult/code element points to the bean declaration for the - resulting combined configuration. In this example we set an attribute + resulting combined configuration. In this example we set some attributes and initialize the node combiner (which is not necessary because the default override combiner is specified) and the expression engine to be used. Note that the codeconfig-class/code attribute makes it @@ -340,7 +340,7 @@ !-- Test configuration definition file that demonstrates complex initialization -- configuration header -result delimiterParsingDisabled=true +result delimiterParsingDisabled=true forceReloadCheck=true expressionEngine config-class=org.apache.commons.configuration.tree.xpath.XPathExpressionEngine/ /result combiner @@ -366,7 +366,19 @@ /configuration ]]/source p - This configuration definition file includes four configuration sources. + This configuration definition file includes four configuration sources and + sets some properties for the resulting codeCombinedConfiguration/code. + Of special interest is the codeforceReloadCheck/code property, which + enables a special check for detecting property changes in the contained + configuration sources. If this property is not set, reloading won't work. + Because we have configured a reloading strategy for one of the included + configuration sources we have to set this flag so that this reloading + strategy can function properly. More details about this topic can be + found in the Javadocs for + codea href=apidocs/org/apache/commons/configuration/CombinedConfiguration.html + CombinedConfiguration/a/code. +/p +p With the following code we can create a codeDefaultConfigurationBuilder/code and load this file: /p - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[transaction] Towards a Commons Transaction 1.2 release
Hi everybody, I wonder if there can finally be a Commons Transaction 1.2 release. Half a year ago we already had a RC 3 [1] which did not get released at that time not due to a specific reason. There were discussions about getting the jars at build time [2]. This issue came up again [3] when talking about a release recently [4]. If somebody wants to do this step I'm fine with it, but IMHO it should not block the release. When doing the step one should also have in mind the necessity of 1.3 compiled Geronimo jars. David Blevins offered to help here [5, 6], but I don't know about any progress (cc-ing him). The code in SVN as is must be built with a JDK 1.4+ to include the JCA stuff. The target JDK 1.3 is addressed automatically by the build system. All other issues like interface compatibility [7] or license headers [8] have been addressed [9] or are obsolete with a new RC. So what is left? I gathered all those links and information as I will be off for the next 5 weeks (New Zealand :) ) and somebody else can jump on the train. I don't know how much time Oliver has. He is rather quiet lately. I'd like to see a Commons Transaction 1.2 release after coming back. Here is my +1 in advance :) Regards Jörg [1] http://marc.theaimsgroup.com/?t=11541897323r=1w=4 [2] http://marc.theaimsgroup.com/?t=11542281691r=1w=4 [3] http://marc.theaimsgroup.com/?t=11681461061r=1w=4 [4] http://marc.theaimsgroup.com/?t=11672486174r=1w=4 [5] http://marc.theaimsgroup.com/?l=jakarta-commons-devm=116838095403943w=4 [6] http://marc.theaimsgroup.com/?l=jakarta-commons-devm=116845728730516w=4 [7] http://marc.theaimsgroup.com/?t=11682925535r=1w=4 [8] http://marc.theaimsgroup.com/?l=jakarta-commons-devm=116783675420686w=4 [9] http://marc.theaimsgroup.com/?l=jakarta-commons-devm=116855776015241w=4 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
splitting commons-dev mailing list (was: [all] Jira reporting)
Joerg Heinicke joerg.heinicke at gmx.de writes: ... splitting it into commons-cvs|svn|scm at jakarta.apache.org, commons-jira|issues|bugs at jakarta.apache.org and the actual dev list for discussions ... I just wanted to ping on this one [1]. There seems to be much agreement about splitting the list [2]. So is there any progress? Jörg [1] http://marc.theaimsgroup.com/?l=jakarta-commons-devm=116813323403039w=4 [2] http://marc.theaimsgroup.com/?t=11677755481r=1w=4 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-jelly-tags-jsl-test (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-jsl-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 6 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-jsl-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on ant exists, no need to add for property maven.jar.ant-optional. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -WARNING- Overriding Maven properties: [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/gump_work/build_commons-jelly_commons-jelly-tags-jsl-test.html Work Name: build_commons-jelly_commons-jelly-tags-jsl-test (Type: Build) Work ended in a state of : Failed Elapsed: 23 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-20012007.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-20012007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-20012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-20012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-20012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-20012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-20012007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-20012007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-20012007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-20012007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-20012007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar - [junit] at org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:64) [junit] at org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:59) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:263) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:66) [junit] at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:113) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:161) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:80) [junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:171) [junit] at
[EMAIL PROTECTED]: Project commons-jelly-tags-jsl-test (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-jsl-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 6 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-jsl-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on ant exists, no need to add for property maven.jar.ant-optional. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -WARNING- Overriding Maven properties: [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/gump_work/build_commons-jelly_commons-jelly-tags-jsl-test.html Work Name: build_commons-jelly_commons-jelly-tags-jsl-test (Type: Build) Work ended in a state of : Failed Elapsed: 23 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-20012007.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-20012007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-20012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-20012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-20012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-20012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-20012007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-20012007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-20012007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-20012007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-20012007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar - [junit] at org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:64) [junit] at org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:59) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:263) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:66) [junit] at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:113) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:161) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:80) [junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:171) [junit] at
[EMAIL PROTECTED]: Project commons-jelly-tags-fmt-test (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-fmt-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 6 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-fmt-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -WARNING- Overriding Maven properties: [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/gump_work/build_commons-jelly_commons-jelly-tags-fmt-test.html Work Name: build_commons-jelly_commons-jelly-tags-fmt-test (Type: Build) Work ended in a state of : Failed Elapsed: 16 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-commands-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-classpath-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-core-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-bsf-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-reflect-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-util-2.0b4.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-20012007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-20012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-20012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/beanshell/target/commons-jelly-tags-beanshell-20012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-20012007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-20012007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-20012007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-20012007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-20012007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/commons-jelly-tags-fmt-20012007.jar - [junit] at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) [junit] at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) [junit] at java.net.URLClassLoader.access$100(URLClassLoader.java:56) [junit] at java.net.URLClassLoader$1.run(URLClassLoader.java:195) [junit] at java.security.AccessController.doPrivileged(Native Method) [junit] at java.net.URLClassLoader.findClass(URLClassLoader.java:188) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:306) [junit] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:251) [junit] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) [junit] at org.apache.commons.jelly.tags.ant.AntTagLibrary.createProject(AntTagLibrary.java:128)
[EMAIL PROTECTED]: Project commons-jelly-tags-fmt-test (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-fmt-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 6 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-fmt-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -WARNING- Overriding Maven properties: [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/gump_work/build_commons-jelly_commons-jelly-tags-fmt-test.html Work Name: build_commons-jelly_commons-jelly-tags-fmt-test (Type: Build) Work ended in a state of : Failed Elapsed: 16 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-commands-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-classpath-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-core-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-bsf-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-reflect-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-util-2.0b4.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-20012007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-20012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-20012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/beanshell/target/commons-jelly-tags-beanshell-20012007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-20012007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-20012007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-20012007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-20012007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-20012007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/commons-jelly-tags-fmt-20012007.jar - [junit] at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) [junit] at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) [junit] at java.net.URLClassLoader.access$100(URLClassLoader.java:56) [junit] at java.net.URLClassLoader$1.run(URLClassLoader.java:195) [junit] at java.security.AccessController.doPrivileged(Native Method) [junit] at java.net.URLClassLoader.findClass(URLClassLoader.java:188) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:306) [junit] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:251) [junit] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) [junit] at org.apache.commons.jelly.tags.ant.AntTagLibrary.createProject(AntTagLibrary.java:128)
Re: [net] FTP reply list never cleared
Hi Niklas Thanks for this, I will apply the patch. Cheers Rory Niklas Gustavsson wrote: Hi When using the net Java 5 branch, the replies returned from the server is stored in a list that is not emptied between commands. This means that when for example printing the replies with a ProtocolCommandListener you will get the full history of replies rather than the last one. The following patch seems to work: Index: src/main/java/org/apache/commons/net/ftp/FTP.java === --- src/main/java/org/apache/commons/net/ftp/FTP.java (revision 497851) +++ src/main/java/org/apache/commons/net/ftp/FTP.java (working copy) @@ -266,7 +266,7 @@ int length; _newReplyString = true; -//_replyLines. setSize(0); +_replyLines.clear(); String line = _controlInput_.readLine(); /niklas - 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] Jira reporting
That sounds nice, but than the vote needs to be on general :) I would be an favor of that.. Mvgr, Martin Dennis Lundberg wrote: Why not move all JIRA notifications to [EMAIL PROTECTED] ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r498153 - in /jakarta/commons/proper/configuration/trunk/xdocs: changes.xml howto_events.xml user_guide.xml
Author: oheger
Date: Sat Jan 20 10:54:31 2007
New Revision: 498153
URL: http://svn.apache.org/viewvc?view=revrev=498153
Log:
CONFIGURATION-245: Updated user guide to cover the new error listener concept
Modified:
jakarta/commons/proper/configuration/trunk/xdocs/changes.xml
jakarta/commons/proper/configuration/trunk/xdocs/howto_events.xml
jakarta/commons/proper/configuration/trunk/xdocs/user_guide.xml
Modified: jakarta/commons/proper/configuration/trunk/xdocs/changes.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/xdocs/changes.xml?view=diffrev=498153r1=498152r2=498153
==
--- jakarta/commons/proper/configuration/trunk/xdocs/changes.xml (original)
+++ jakarta/commons/proper/configuration/trunk/xdocs/changes.xml Sat Jan 20
10:54:31 2007
@@ -23,6 +23,11 @@
body
release version=1.4-dev date=in SVN
+ action dev=oheger type=add issue=CONFIGURATION-245
+In addition to configuration event listeners now so-called
configuration
+error listeners are supported. These listeners are notified about
+internal errors that had been logged and swallowed by privious
versions.
+ /action
action dev=oheger type=add
AbstractConfiguration now allows to set an instance specific logger
using the setLogger() method. This gives clients more control over a
Modified: jakarta/commons/proper/configuration/trunk/xdocs/howto_events.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/xdocs/howto_events.xml?view=diffrev=498153r1=498152r2=498153
==
--- jakarta/commons/proper/configuration/trunk/xdocs/howto_events.xml (original)
+++ jakarta/commons/proper/configuration/trunk/xdocs/howto_events.xml Sat Jan
20 10:54:31 2007
@@ -129,6 +129,102 @@
config.addProperty(newProperty, newValue); // will fire an event
]]/source
/subsection
+subsection name=Error listeners
+p
+ Some implementations of the codeConfiguration/code interface operate
+ on underlying storages that can throw exceptions on each property access.
+ As an example consider code
+ a
href=apidocs/org/apache/commons/configuration/DatabaseConfiguration.html
+ DatabaseConfiguration/a/code: this configuration class issues an SQL
+ statement for each accessed property, which can potentially cause a
+ codeSQLException/code.
+/p
+p
+ In earlier versions of emCommons Configuration/em such exceptions
+ were simply logged and then swallowed. So for clients it was impossible
+ to find out if something went wrong. From version 1.4 on there is a new
+ way of dealing with those internal errors: the concept of emerror
+ listeners/em.
+/p
+p
+ A configuration error listener is very similar to a regular configuration
+ event listener. Instead of the codeConfigurationListener/code
+ interface it has to implement the
+ codea
href=apidocs/org/apache/commons/configuration/event/ConfigurationErrorListener.html
+ ConfigurationErrorListener/a/code interface, which defines a single
method
+ codeconfigurationError()/code. In case of an internal error this
+ method is invoked, and a
+ codea
href=apidocs/org/apache/commons/configuration/event/ConfigurationErrorEvent.html
+ ConfigurationErrorEvent/a/code with information about that error is
+ passed. By inheriting from codeConfigurationEvent/code
+ codeConfigurationErrorEvent/code supports all information that is
+ available for normal configuration listeners, too (e.g. the event type or
+ the property that was accessed when the problem occurred; note that the
+ codeisBefore()/code method does not really make sense for error
+ events because an error can only occur after something was done, so it
+ returns always bfalse/b is this context). This data can
+ be used to find out when and where the error happened. In addition there
+ is the codegetCause()/code method that returns the
codeThrowable/code
+ object, which generated this event (i.e. the causing exception).
+/p
+p
+ We can now continue our example from the previous section and make our
+ example configuration listener also capable of tracing error events. To
+ achieve this we let the codeConfigurationLogListener/code class also
+ implement the codeConfigurationErrorListener/code interface:
+/p
+source
+import org.apache.commons.configuration.event.ConfigurationEvent;
+import org.apache.commons.configuration.event.ConfigurationListener;
+bimport org.apache.commons.configuration.event.ConfigurationListener;/b
+
+public class ConfigurationLogListener
+ implements ConfigurationListener, bConfigurationErrorListener/b
+{
+public void configurationChanged(ConfigurationEvent event)
+{
+
[jira] Resolved: (CONFIGURATION-245) DatabaseConfiguration and JNDIConfiguration are eating exceptions
[ https://issues.apache.org/jira/browse/CONFIGURATION-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-245. Resolution: Fixed Fix Version/s: 1.4 The concept of error listeners was implemented. It is now possible for an interested client to register itself as an error listener at a configuration. It is then notified about internal errors. DatabaseConfiguration, JNDIConfiguration, and AbstractFileConfiguration use this new concept for reporting internal errors. DatabaseConfiguration and JNDIConfiguration are eating exceptions - Key: CONFIGURATION-245 URL: https://issues.apache.org/jira/browse/CONFIGURATION-245 Project: Commons Configuration Issue Type: Bug Affects Versions: Nightly Builds, 1.3 Final Reporter: Hal Deadman Assigned To: Oliver Heger Fix For: 1.4 DatabaseConfiguration and JNDIConfiguration and possibly others, really need to throw some sort of runtime exception to let the caller know the properties couldn't be read. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://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] Commented: (CONFIGURATION-249) save to URLs with a protocol other than file:
[ https://issues.apache.org/jira/browse/CONFIGURATION-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466267 ] Oliver Heger commented on CONFIGURATION-249: A patch would be highly appreciated. If you could provide a unit test for the new feature, too, this would be even better. Thank you very much. save to URLs with a protocol other than file: --- Key: CONFIGURATION-249 URL: https://issues.apache.org/jira/browse/CONFIGURATION-249 Project: Commons Configuration Issue Type: Improvement Affects Versions: 1.4 Reporter: Anselm Kruis Priority: Minor Fix For: 1.4 Currently, the save(URL) method from AbstractFileConfiguration only supports file: URLs. Why not support writing to URLs too? It is as simple like this java.net.URLConnection connection = url.openConnection(); connection.setDoOutput(true); connection.setDoInput(false); save(connection.getOutputStream()); I could prepare a patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://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]
svn commit: r498155 - /jakarta/commons/proper/configuration/trunk/build.xml
Author: oheger
Date: Sat Jan 20 11:23:52 2007
New Revision: 498155
URL: http://svn.apache.org/viewvc?view=revrev=498155
Log:
CONFIGURATION-250: Updated dependencies in build.xml so that they match with
project.xml
Modified:
jakarta/commons/proper/configuration/trunk/build.xml
Modified: jakarta/commons/proper/configuration/trunk/build.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/build.xml?view=diffrev=498155r1=498154r2=498155
==
--- jakarta/commons/proper/configuration/trunk/build.xml (original)
+++ jakarta/commons/proper/configuration/trunk/build.xml Sat Jan 20 11:23:52
2007
@@ -233,7 +233,7 @@
/setproxy
get dest=${libdir}/commons-collections-3.1.jar usetimestamp=true
ignoreerrors=true
src=http://www.ibiblio.org/maven/commons-collections/jars/commons-collections-3.1.jar;
/get
-get dest=${libdir}/commons-lang-2.1.jar usetimestamp=true
ignoreerrors=true
src=http://www.ibiblio.org/maven/commons-lang/jars/commons-lang-2.1.jar;
+get dest=${libdir}/commons-lang-2.2.jar usetimestamp=true
ignoreerrors=true
src=http://www.ibiblio.org/maven/commons-lang/jars/commons-lang-2.2.jar;
/get
get dest=${libdir}/commons-logging-1.0.4.jar usetimestamp=true
ignoreerrors=true
src=http://www.ibiblio.org/maven/commons-logging/jars/commons-logging-1.0.4.jar;
/get
@@ -251,7 +251,7 @@
/get
get dest=${libdir}/xml-apis-2.0.2.jar usetimestamp=true
ignoreerrors=true
src=http://www.ibiblio.org/maven/xml-apis/jars/xml-apis-2.0.2.jar;
/get
-get dest=${libdir}/servletapi-2.3.jar usetimestamp=true
ignoreerrors=true
src=http://www.ibiblio.org/maven/servletapi/jars/servletapi-2.3.jar;
+get dest=${libdir}/servletapi-2.4.jar usetimestamp=true
ignoreerrors=true
src=http://www.ibiblio.org/maven/servletapi/jars/servletapi-2.4.jar;
/get
get dest=${libdir}/spice-jndikit-1.1.jar usetimestamp=true
ignoreerrors=true
src=http://www.ibiblio.org/maven/spice/jars/spice-jndikit-1.1.jar;
/get
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-250) build.xml file fetches the wrong version of commons-lang
[ https://issues.apache.org/jira/browse/CONFIGURATION-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-250. Resolution: Fixed Fix Version/s: 1.4 Fixed in subversion. Thank you for the spot. build.xml file fetches the wrong version of commons-lang Key: CONFIGURATION-250 URL: https://issues.apache.org/jira/browse/CONFIGURATION-250 Project: Commons Configuration Issue Type: Bug Affects Versions: Nightly Builds Reporter: Anselm Kruis Assigned To: Oliver Heger Priority: Trivial Fix For: 1.4 The build.xml fetches commons-lang-2.1.jar instead of commons-lang-2.2.jar. Seems to be related to the change 2006-12-23 17:36 oheger * [r489906] project.properties, project.xml: Updated dependency to lang 2.2, minor site improvements Fix is trivial. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://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: (CONFIGURATION-215) Using relative URLs
[
https://issues.apache.org/jira/browse/CONFIGURATION-215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger updated CONFIGURATION-215:
---
Fix Version/s: 1.5
Affects Version/s: 1.3 Final
Setting fix version to release 1.5, assuming that 1.4 can come out soon. A
solution of this problem would also be helpful for the requested feature of
saving back changes made at a composite configuration.
Using relative URLs
---
Key: CONFIGURATION-215
URL: https://issues.apache.org/jira/browse/CONFIGURATION-215
Project: Commons Configuration
Issue Type: Improvement
Affects Versions: 1.3 Final
Reporter: Michiel Kalkman
Priority: Minor
Fix For: 1.5
It would be useful to be able to specify URLs in configuration item values
that are relative to the configuration.
A sample. I have the following files.
A/config.xml which refers to
B/specificConfigForB.xml which refers to
B/somefile
Now specifying the location of somefile in specificConfigForB.xml should be
possible using a relative URL, such that it is possible to retrieve the
absolute URL of somefile through:
a) the absolute URL of A/config.xml (e.g.: file:/c:/A/config.xml or
http://A/config.xml)
b) the relative URL of somefile specified in B/specificConfigForB.xml (like
somefilesomefile/somefile)
(1) One solution is to make it possible to find the location of the
configuration file that specifies the relative URL. Or more general, commons
config should know where a given configuration item is stored.
In this case it might be an idea to implement a getURL() on the Configuration
interface which uses:
1. the absolute URL of the composite configuration file, (A/config.xml)
2. the relative URL to the specfying configuration file,
(B/specificConfigForB.xml)
3. the relative URL specified (in B/specificConfigForB.xml)
(2) Another solution is to specify a special meta variable (like ${url}) that
can be used to specify the location of the specifying configuration file wrt
the composite configuration file. E.g. somefile${url}/somefile/somefile
would result in ../B/somefile.
(3) Another solution would be to specify a special attribute to indicate that
the value specified is an URL. Like somefile type=URLsomefile/somefile.
The advantage of solution (1) is that no extra semantics are introduced to
the configuration files. Furthermore, it might possibly be useful in
debugging situations. The advantages of solution (2) is that in this manner
other meta variables might be introduced. The disadvantage of solution (3) is
that this one cannot be applied to property files.
See also
http://mail-archives.apache.org/mod_mbox/jakarta-commons-user/200606.mbox/[EMAIL
PROTECTED]
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://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]
svn commit: r498159 - /jakarta/commons/proper/net/branches/JDK_1_5_BRANCH/src/main/java/org/apache/commons/net/ftp/FTP.java
Author: rwinston Date: Sat Jan 20 11:44:52 2007 New Revision: 498159 URL: http://svn.apache.org/viewvc?view=revrev=498159 Log: Clear reply lines list Modified: jakarta/commons/proper/net/branches/JDK_1_5_BRANCH/src/main/java/org/apache/commons/net/ftp/FTP.java Modified: jakarta/commons/proper/net/branches/JDK_1_5_BRANCH/src/main/java/org/apache/commons/net/ftp/FTP.java URL: http://svn.apache.org/viewvc/jakarta/commons/proper/net/branches/JDK_1_5_BRANCH/src/main/java/org/apache/commons/net/ftp/FTP.java?view=diffrev=498159r1=498158r2=498159 == --- jakarta/commons/proper/net/branches/JDK_1_5_BRANCH/src/main/java/org/apache/commons/net/ftp/FTP.java (original) +++ jakarta/commons/proper/net/branches/JDK_1_5_BRANCH/src/main/java/org/apache/commons/net/ftp/FTP.java Sat Jan 20 11:44:52 2007 @@ -266,7 +266,7 @@ int length; _newReplyString = true; -//_replyLines. setSize(0); +_replyLines.clear(); String line = _controlInput_.readLine(); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (NET-91) commons.net.FTPClient hangs on disconnect or logout
[
https://issues.apache.org/jira/browse/NET-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rory Winston closed NET-91.
---
commons.net.FTPClient hangs on disconnect or logout
---
Key: NET-91
URL: https://issues.apache.org/jira/browse/NET-91
Project: Commons Net
Issue Type: Bug
Affects Versions: 1.4 Final
Environment: Operating System: All
Platform: PC
Reporter: Joe
By repetitively calling
try {
// connect and login to the FTP server
ftpc.connect(getPropertyFromEnv(FTP_SERVER));
ftpc.login(getPropertyFromEnv(USERNAME), getPropertyFromEnv
(PASSWORD)); //technically we may have to break this into 2 blocks see
examples
// After connection attempt, check the reply code to verify
success.
reply = ftpc.getReplyCode();
response = ftpc.getReplyString();
if(!FTPReply.isPositiveCompletion(reply)) {
System.err.println(FTP server refused connection or login.);
killFTP(ftpc);
ftpc = null;
}
} catch(IOException e) {
System.err.println(Can't connect or login to server, reply
= +reply+ response = + response);
killFTP(ftpc);
ftpc = null;
}
and then
if (ftpc.isConnected()) {
try {
ftpc.logout();
} catch (Exception e) { // do nothing
System.out.println(Exception in ftpc.logout());
}
try {
ftpc.disconnect();
} catch (Exception e) { // do nothing
System.out.println(Exception in ftpc.disconnect());
}
}
one of the two bottom calls hangs and I'm assuming that it's in an infinite
loop waiting for something that the server isn't sending. We try and hook to
a Linux FTP server, and Windows FTP server and 99.99 % of the time it works,
but every once in a while, it hangs and we have to kill the FTP daemon.
After
doing that everything works again!!!
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://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]
