[nightly build] configuration failed.

2007-04-21 Thread Phil Steitz
Failed build logs:
http://vmbuild.apache.org/~commons/nightly/logs//20070421/configuration.log

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



svn commit: r531027 - in /jakarta/commons/proper/collections/trunk: RELEASE-NOTES.html src/java/org/apache/commons/collections/list/SetUniqueList.java src/test/org/apache/commons/collections/list/Test

2007-04-21 Thread bayard
Author: bayard
Date: Sat Apr 21 06:44:46 2007
New Revision: 531027

URL: http://svn.apache.org/viewvc?view=revrev=531027
Log:
Applying Joe Kelly's fix for COLLECTIONS-249 - SetUniqueList.addAll(int, 
Collection
) was always inserting at the end of the list

Modified:
jakarta/commons/proper/collections/trunk/RELEASE-NOTES.html

jakarta/commons/proper/collections/trunk/src/java/org/apache/commons/collections/list/SetUniqueList.java

jakarta/commons/proper/collections/trunk/src/test/org/apache/commons/collections/list/TestSetUniqueList.java

Modified: jakarta/commons/proper/collections/trunk/RELEASE-NOTES.html
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/collections/trunk/RELEASE-NOTES.html?view=diffrev=531027r1=531026r2=531027
==
--- jakarta/commons/proper/collections/trunk/RELEASE-NOTES.html (original)
+++ jakarta/commons/proper/collections/trunk/RELEASE-NOTES.html Sat Apr 21 
06:44:46 2007
@@ -59,6 +59,7 @@
 liExtendedProperties - Include property name had confused static/instance 
semantics [COLLECTIONS-214]/li
 liCollectionUtils - Fix removeAll() method which was completely broken 
[COLLECTIONS-219]/li
 liMultiValueMap - Fix put() and putAll() to return correct results 
[COLLECTIONS-228]/li
+liSetUniqueList - addAll(int, Collection) fixed to properly insert at the 
specified index [COLLECTIONS-249]/li
 /ul
 
 centerh3JAVADOC/h3/center

Modified: 
jakarta/commons/proper/collections/trunk/src/java/org/apache/commons/collections/list/SetUniqueList.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/collections/trunk/src/java/org/apache/commons/collections/list/SetUniqueList.java?view=diffrev=531027r1=531026r2=531027
==
--- 
jakarta/commons/proper/collections/trunk/src/java/org/apache/commons/collections/list/SetUniqueList.java
 (original)
+++ 
jakarta/commons/proper/collections/trunk/src/java/org/apache/commons/collections/list/SetUniqueList.java
 Sat Apr 21 06:44:46 2007
@@ -155,20 +155,25 @@
 }
 
 /**
- * Adds an element to the end of the list if it is not already present.
+ * Adds a collection of objects to the end of the list avoiding duplicates.
+ * p
+ * Only elements that are not already in this list will be added, and
+ * duplicates from the specified collection will be ignored.
  * p
  * i(Violation)/i
- * The codeList/code interface makes the assumption that the element is
- * always inserted. This may not happen with this implementation.
+ * The codeList/code interface makes the assumption that the elements
+ * are always inserted. This may not happen with this implementation.
  * 
- * @param coll  the collection to add
+ * @param coll  the collection to add in iterator order
+ * @return true if this collection changed
  */
 public boolean addAll(Collection coll) {
 return addAll(size(), coll);
 }
 
 /**
- * Adds a collection of objects to the end of the list avoiding duplicates.
+ * Adds a collection of objects a specific index in the list avoiding 
+ * duplicates.
  * p
  * Only elements that are not already in this list will be added, and
  * duplicates from the specified collection will be ignored.
@@ -187,7 +192,12 @@
 
 // adds all elements
 for (final Iterator it = coll.iterator(); it.hasNext();) {
-add(it.next());
+int sizeBeforeAddNext = size();
+add(index, it.next());
+// if it was inserted, then increase the target index
+if (sizeBeforeAddNext != size()) {
+  index++;
+}
 }
 
 // compares sizes to detect if collection changed

Modified: 
jakarta/commons/proper/collections/trunk/src/test/org/apache/commons/collections/list/TestSetUniqueList.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/collections/trunk/src/test/org/apache/commons/collections/list/TestSetUniqueList.java?view=diffrev=531027r1=531026r2=531027
==
--- 
jakarta/commons/proper/collections/trunk/src/test/org/apache/commons/collections/list/TestSetUniqueList.java
 (original)
+++ 
jakarta/commons/proper/collections/trunk/src/test/org/apache/commons/collections/list/TestSetUniqueList.java
 Sat Apr 21 06:44:46 2007
@@ -144,6 +144,31 @@
 assertEquals(Size should increase after addAll, 
  size + elements.length, collection.size());
 }
+
+public void testIntCollectionAddAll() {
+  // make a SetUniqueList with one element
+  List list = new SetUniqueList(new ArrayList(), new HashSet());
+  final Integer existingElement = new Integer(1);
+  list.add(existingElement);
+
+  // add two new unique elements at index 0
+  final Integer firstNewElement = new Integer(2);
+  

[jira] Closed: (COLLECTIONS-249) SetUniqueList.addAll(int index, Collection coll) adds to end of list instead of at specified index

2007-04-21 Thread Henri Yandell (JIRA)

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

Henri Yandell closed COLLECTIONS-249.
-

   Resolution: Fixed
Fix Version/s: 3.3


Nice find Joe, patches applied to trunk.

svn ci -m Applying Joe Kelly's fix for COLLECTIONS-249 - 
SetUniqueList.addAll(int, Collection ) was always inserting at the end of the 
list 

SendingRELEASE-NOTES.html
Sendingsrc/java/org/apache/commons/collections/list/SetUniqueList.java
Sending
src/test/org/apache/commons/collections/list/TestSetUniqueList.java
Transmitting file data ...
Committed revision 531027.

 SetUniqueList.addAll(int index, Collection coll) adds to end of list instead 
 of at specified index
 --

 Key: COLLECTIONS-249
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-249
 Project: Commons Collections
  Issue Type: Bug
  Components: List
Affects Versions: 3.2
Reporter: Joe Kelly
Priority: Minor
 Fix For: 3.3

 Attachments: SetUniqueList.patch, TestSetUniqueList.patch


 When you call SetUniqueList.addAll(int index, Collection coll), it 
 incorrectly adds the new elements to the end of the list instead of at the 
 specified index.

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


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



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

2007-04-21 Thread oheger
Author: oheger
Date: Sat Apr 21 07:31:58 2007
New Revision: 531038

URL: http://svn.apache.org/viewvc?view=revrev=531038
Log:
CONFIGURATION-264: Added a new mode to SubnodeConfiguration, in which it checks 
for structural changes of its parent. In this mode it is able to detect 
reloads, too.

Modified:

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

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

jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestSubnodeConfiguration.java
jakarta/commons/proper/configuration/trunk/xdocs/changes.xml
jakarta/commons/proper/configuration/trunk/xdocs/userguide/howto_xml.xml

Modified: 
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/HierarchicalConfiguration.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/HierarchicalConfiguration.java?view=diffrev=531038r1=531037r2=531038
==
--- 
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/HierarchicalConfiguration.java
 (original)
+++ 
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/HierarchicalConfiguration.java
 Sat Apr 21 07:31:58 2007
@@ -458,13 +458,36 @@
  * codeSubnodeConfiguration/code class to obtain further information
  * about subnode configurations and when they should be used.
  * /p
+ * p
+ * With the codesupportUpdate/code flag the behavior of the returned
+ * codeSubnodeConfiguration/code regarding updates of its parent
+ * configuration can be determined. A subnode configuration operates on the
+ * same nodes as its parent, so changes at one configuration are normally
+ * directly visible for the other configuration. There are however changes
+ * of the parent configuration, which are not recognized by the subnode
+ * configuration per default. An example for this is a reload operation 
(for
+ * file-based configurations): Here the complete node set of the parent
+ * configuration is replaced, but the subnode configuration still 
references
+ * the old nodes. If such changes should be detected by the subnode
+ * configuration, the codesupportUpdates/code flag must be set to
+ * btrue/b. This causes the subnode configuration to reevaluate the key
+ * used for its creation each time it is accessed. This guarantees that the
+ * subnode configuration always stays in sync with its key, even if the
+ * parent configuration's data significantly changes. If such a change
+ * makes the key invalid - because it now no longer points to exactly one
+ * node -, the subnode configuration is not reconstructed, but keeps its
+ * old data. It is then quasi detached from its parent.
+ * /p
  *
  * @param key the key that selects the sub tree
+ * @param supportUpdates a flag whether the returned subnode configuration
+ * should be able to handle updates of its parent
  * @return a hierarchical configuration that contains this sub tree
  * @see SubnodeConfiguration
- * @since 1.3
+ * @since 1.5
  */
-public SubnodeConfiguration configurationAt(String key)
+public SubnodeConfiguration configurationAt(String key,
+boolean supportUpdates)
 {
 List nodes = fetchNodeList(key);
 if (nodes.size() != 1)
@@ -472,7 +495,24 @@
 throw new IllegalArgumentException(
 Passed in key must select exactly one node:  + key);
 }
-return createSubnodeConfiguration((ConfigurationNode) nodes.get(0));
+return supportUpdates ? createSubnodeConfiguration(
+(ConfigurationNode) nodes.get(0), key)
+: createSubnodeConfiguration((ConfigurationNode) nodes.get(0));
+}
+
+/**
+ * Returns a hierarchical subnode configuration for the node specified by
+ * the given key. This is a short form for codeconfigurationAt(key,
+ * bfalse/b)/code.
+ *
+ * @param key the key that selects the sub tree
+ * @return a hierarchical configuration that contains this sub tree
+ * @see SubnodeConfiguration
+ * @since 1.3
+ */
+public SubnodeConfiguration configurationAt(String key)
+{
+return configurationAt(key, false);
 }
 
 /**
@@ -525,6 +565,24 @@
 protected SubnodeConfiguration 
createSubnodeConfiguration(ConfigurationNode node)
 {
 return new SubnodeConfiguration(this, node);
+}
+
+/**
+ * Creates a new subnode configuration for the specified node and sets its
+ * construction key. A subnode configuration created this way will be aware
+ * of structural changes of its parent.
+ *
+  

[jira] Resolved: (CONFIGURATION-264) SubnodeConfiguration does not see reloads of its parent configuration

2007-04-21 Thread Oliver Heger (JIRA)

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

Oliver Heger resolved CONFIGURATION-264.


Resolution: Fixed

A fix was applied that implements the changes outlined before. 
HierarchicalConfiguration's configurationAt() method now supports an additional 
boolean parameter. If this parameter is set to true, reloads of the parent 
configuration will be detected.

 SubnodeConfiguration does not see reloads of its parent configuration
 -

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


 The problem can be reproduced as follows:
 1 config = new XMLConfiguration(c:\\conf.xml);
 2 config.setReloadingStrategy(new FileChangedReloadingStrategy());
 3 SubnodeConfiguration parentItemConfig = 
 config.configurationAt(parent-item);
 4 String ss2 = parentItemConfig.getString(sub-item);
 5 //Now, sub-item node value changes to new_value
 6 ss2 = parentItemConfig.getString(sub-item); // still returns old_value

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


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



svn commit: r531047 - in /jakarta/commons/proper/configuration/trunk: ./ src/java/org/apache/commons/configuration/plist/ src/test/org/apache/commons/configuration/event/ src/test/org/apache/commons/c

2007-04-21 Thread oheger
Author: oheger
Date: Sat Apr 21 08:23:08 2007
New Revision: 531047

URL: http://svn.apache.org/viewvc?view=revrev=531047
Log:
Reviewed event handling in plist configurations; added new test classes

Added:

jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/plist/AbstractTestPListEvents.java
   (with props)

jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/plist/TestPropertyListConfigurationEvents.java
   (with props)

jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/plist/TestXMLPropertyListConfigurationEvents.java
   (with props)
Modified:
jakarta/commons/proper/configuration/trunk/build.xml
jakarta/commons/proper/configuration/trunk/project.xml

jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/plist/PropertyListConfiguration.java

jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/plist/XMLPropertyListConfiguration.java

jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/event/AbstractTestConfigurationEvents.java

Modified: jakarta/commons/proper/configuration/trunk/build.xml
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/build.xml?view=diffrev=531047r1=531046r2=531047
==
--- jakarta/commons/proper/configuration/trunk/build.xml (original)
+++ jakarta/commons/proper/configuration/trunk/build.xml Sat Apr 21 08:23:08 
2007
@@ -164,6 +164,7 @@
   exclude name=**/AbstractCombinerTest.java/
   exclude name=**/AbstractTestConfigurationEvents.java/
   exclude name=**/AbstractTestFileConfigurationEvents.java/
+  exclude name=**/AbstractTestPListEvents.java/
 /fileset
   /batchtest
 /junit

Modified: jakarta/commons/proper/configuration/trunk/project.xml
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/project.xml?view=diffrev=531047r1=531046r2=531047
==
--- jakarta/commons/proper/configuration/trunk/project.xml (original)
+++ jakarta/commons/proper/configuration/trunk/project.xml Sat Apr 21 08:23:08 
2007
@@ -524,6 +524,7 @@
 exclude**/AbstractCombinerTest.java/exclude
 exclude**/AbstractTestConfigurationEvents.java/exclude
 exclude**/AbstractTestFileConfigurationEvents.java/exclude
+exclude**/AbstractTestPListEvents.java/exclude
   /excludes
   resources
 resource

Modified: 
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/plist/PropertyListConfiguration.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/plist/PropertyListConfiguration.java?view=diffrev=531047r1=531046r2=531047
==
--- 
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/plist/PropertyListConfiguration.java
 (original)
+++ 
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/plist/PropertyListConfiguration.java
 Sat Apr 21 08:23:08 2007
@@ -146,8 +146,18 @@
 // special case for byte arrays, they must be stored as is in the 
configuration
 if (value instanceof byte[])
 {
-clearProperty(key);
-addPropertyDirect(key, value);
+fireEvent(EVENT_SET_PROPERTY, key, value, true);
+setDetailEvents(false);
+try
+{
+clearProperty(key);
+addPropertyDirect(key, value);
+}
+finally
+{
+setDetailEvents(true);
+}
+fireEvent(EVENT_SET_PROPERTY, key, value, false);
 }
 else
 {
@@ -165,7 +175,7 @@
 }
 else
 {
-super.setProperty(key, value);
+super.addProperty(key, value);
 }
 }
 

Modified: 
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/plist/XMLPropertyListConfiguration.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/plist/XMLPropertyListConfiguration.java?view=diffrev=531047r1=531046r2=531047
==
--- 
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/plist/XMLPropertyListConfiguration.java
 (original)
+++ 
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/plist/XMLPropertyListConfiguration.java
 Sat Apr 21 08:23:08 2007
@@ -186,8 +186,18 @@
 // special case for byte arrays, they must be stored as is in the 
configuration

Re: [Commons Configuration] using setProperty for data element on XML plist

2007-04-21 Thread Oliver Heger

Emmanuel Bourg wrote:

Oliver Heger a écrit :

Okay, I will have a look and write test cases for the events. From a 
first glance it seems that CLEAR_PROPERTY and AND_PROPERTY events are 
thrown instead of a SET_PROPERTY event.


Thank you. Is there a mechanism to disable the clear and add events ?

Done. Yes, with a call to setDetailEvents(false) nested events can be 
disabled. As it is implemented now, the setProperty() method triggers 
only SET_PROPERTY events.


Oliver

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



[jira] Created: (VFS-128) Sync task does not delete unneeded files

2007-04-21 Thread Frank (JIRA)
Sync task does not delete unneeded files


 Key: VFS-128
 URL: https://issues.apache.org/jira/browse/VFS-128
 Project: Commons VFS
  Issue Type: Bug
Affects Versions: 1.1
Reporter: Frank
Priority: Minor


When the Sync Ant task encounters a file that is not available in the source 
directory it writes to the log that it deletes the superfluous file, but it 
does not actually does it.

In SyncTask I found that the line doing the delete is commented out:

protected void handleMissingSourceFile(final FileObject destFile)
throws Exception
{
log(deleting  + destFile);
//destFile.delete( Selectors.SELECT_SELF );
}

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


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



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

2007-04-21 Thread commons-jelly-tags-jsl development
To whom it may engage...

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

Project commons-jelly-tags-jsl-test has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 153 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: 16 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-21042007.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-21042007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-21042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-21042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-21042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-21042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-21042007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-21042007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-21042007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-21042007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-21042007.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] 

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

2007-04-21 Thread commons-jelly-tags-jsl development
To whom it may engage...

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

Project commons-jelly-tags-jsl-test has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 153 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: 16 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-21042007.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-21042007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-21042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-21042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-21042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-21042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-21042007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-21042007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-21042007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-21042007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-21042007.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] 

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

2007-04-21 Thread commons-jelly-tags-fmt development
To whom it may engage...

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

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


Full details are available at:

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

That said, some information snippets are provided here.

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



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

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

2007-04-21 Thread commons-jelly-tags-fmt development
To whom it may engage...

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

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


Full details are available at:

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

That said, some information snippets are provided here.

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



The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/gump_work/build_commons-jelly_commons-jelly-tags-fmt-test.html
Work Name: build_commons-jelly_commons-jelly-tags-fmt-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 11 secs
Command Line: maven --offline jar 
[Working Directory: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt]
CLASSPATH: 
/opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-commands-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-classpath-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-core-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-bsf-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-reflect-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-util-2.0b4.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-21042007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-21042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-21042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/beanshell/target/commons-jelly-tags-beanshell-21042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-21042007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-21042007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-21042007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-21042007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-21042007.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-21042007.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)

svn commit: r531087 - in /jakarta/commons/proper/configuration/trunk: src/java/org/apache/commons/configuration/interpol/ConfigurationInterpolator.java src/test/org/apache/commons/configuration/interp

2007-04-21 Thread oheger
Author: oheger
Date: Sat Apr 21 12:03:58 2007
New Revision: 531087

URL: http://svn.apache.org/viewvc?view=revrev=531087
Log:
CONFIGURATION-266: ConfigurationInterpolator now also invokes the default 
lookup object for variables with a prefix that could not be resolved by their 
associated lookup object. Thanks to Tobias Noebel.

Modified:

jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/interpol/ConfigurationInterpolator.java

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

Modified: 
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/interpol/ConfigurationInterpolator.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/interpol/ConfigurationInterpolator.java?view=diffrev=531087r1=531086r2=531087
==
--- 
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/interpol/ConfigurationInterpolator.java
 (original)
+++ 
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/interpol/ConfigurationInterpolator.java
 Sat Apr 21 12:03:58 2007
@@ -29,7 +29,7 @@
  * /p
  * p
  * Each instance of codeAbstractConfiguration/code is associated with an
- * object of this class. Each interpolation tasks are delegated to this object.
+ * object of this class. All interpolation tasks are delegated to this object.
  * /p
  * p
  * codeConfigurationInterpolator/code works together with the
@@ -40,13 +40,14 @@
  * /p
  * p
  * The basic idea of this class is that it can maintain a set of primitive
- * codeStrLookup/code objects, each of which are identified by a special
+ * codeStrLookup/code objects, each of which is identified by a special
  * prefix. The variables to be processed have the form
  * code${prefix:name}/code. codeConfigurationInterpolator/code will
  * extract the prefix and determine, which primitive lookup object is 
registered
  * for it. Then the name of the variable is passed to this object to obtain the
  * actual value. It is also possible to define a default lookup object, which
- * will be used for variables that do not have a prefix.
+ * will be used for variables that do not have a prefix or that cannot be
+ * resolved by their associated lookup object.
  * /p
  * p
  * When a new instance of this class is created it is initialized with a 
default
@@ -92,8 +93,8 @@
  * Implementation node: Instances of this class are not thread-safe related to
  * modifications of their current set of registered lookup objects. It is
  * intended that each instance is associated with a single
- * codeConfiguration/conde
- * object and used for its interpolation tasks./p
+ * codeConfiguration/code object and used for its interpolation tasks.
+ * /p
  *
  * @version $Id$
  * @since 1.4
@@ -262,7 +263,8 @@
  * a variable prefix from the given variable name (the first colon (':') is
  * used as prefix separator). It then passes the name of the variable with
  * the prefix stripped to the lookup object registered for this prefix. If
- * no prefix can be found, the default lookup object will be used.
+ * no prefix can be found or if the associated lookup object cannot resolve
+ * this variable, the default lookup object will be used.
  *
  * @param var the name of the variable whose value is to be looked up
  * @return the value of this variable or bnull/b if it cannot be
@@ -274,18 +276,19 @@
 {
 return null;
 }
-
+
 int prefixPos = var.indexOf(PREFIX_SEPARATOR);
-if (prefixPos  0)
-{
-return fetchNoPrefixLookup().lookup(var);
-}
-else
+if (prefixPos = 0)
 {
 String prefix = var.substring(0, prefixPos);
 String name = var.substring(prefixPos + 1);
-return fetchLookupForPrefix(prefix).lookup(name);
+String value = fetchLookupForPrefix(prefix).lookup(name);
+if (value != null) 
+{
+return value;
+}
 }
+return fetchNoPrefixLookup().lookup(var);
 }
 
 /**

Modified: 
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/interpol/TestConfigurationInterpolator.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/interpol/TestConfigurationInterpolator.java?view=diffrev=531087r1=531086r2=531087
==
--- 
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/interpol/TestConfigurationInterpolator.java
 (original)
+++ 

[jira] Resolved: (CONFIGURATION-266) Improving backward compatibility in ConfigurationInterpolator

2007-04-21 Thread Oliver Heger (JIRA)

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

Oliver Heger resolved CONFIGURATION-266.


Resolution: Fixed

The patch was applied. Many thanks!

 Improving backward compatibility in ConfigurationInterpolator
 -

 Key: CONFIGURATION-266
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-266
 Project: Commons Configuration
  Issue Type: Improvement
Affects Versions: 1.4
Reporter: Tobias Noebel
 Assigned To: Oliver Heger
 Fix For: 1.5

 Attachments: ConfigurationInterpolator.diff, 
 ConfigurationInterpolator.java


 When using variables with prefixes in previous versions of commons 
 configuration one could use the default lookup to assign the variable values, 
 as prefixes were not recognized and handled differently. Since 1.4 that 
 behaviour is broken as the default lookup is not taken into account for 
 variables containing prefixes. Applications which make use of such variables 
 would have to be changed.
 My request is to use the default lookup as fallback if a variable with prefix 
 is not found in the local lookups.

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


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



[jira] Commented: (CONFIGURATION-3) Drop 1st class dependency on commons-logging

2007-04-21 Thread Oliver Heger (JIRA)

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

Oliver Heger commented on CONFIGURATION-3:
--

Should a generic library like Commons Configuration really depend on a specific 
logging library? I think log4j is still in wide use, and if an application that 
uses this library wanted to include a dependency to Configuration, there would 
be two logging implementations to be handled.

But my knowledge about logging implementations is a bit outdated. This may not 
be a problem these days any more.

 Drop 1st class dependency on commons-logging
 

 Key: CONFIGURATION-3
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-3
 Project: Commons Configuration
  Issue Type: Improvement
Affects Versions: 1.2
Reporter: Joerg Schaible
Priority: Minor
 Fix For: 2.0


 Currently commons-logging is reported as first class dependency in the project
 reports. This is not true. The only classes that make direct usage of JCL are
 ConfigurationDynaBean/Class and this only for tracing. It would be nice to
 eliminate this reference at all and list JCL only as transitive dependency of
 digester and beanutils.
 We might support logging with the monitor/listener concept of
 http://issues.apache.org/bugzilla/show_bug.cgi?id=38929

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


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



[jira] Commented: (CONFIGURATION-265) XMLConfiguration with setAutoSave(true) doesn't save if SubnodeConfiguration is changed

2007-04-21 Thread Oliver Heger (JIRA)

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

Oliver Heger commented on CONFIGURATION-265:


This is indeed a bug, updates in the subnode configuration do not trigger the 
parent's auto-save mechanism.

To be consequent, these updates should then also generate change events for the 
parent configuration. However this will be problematic because we cannot simply 
transform the configuration key used by the subnode configuration into the 
namespace of the parent (the expression engines do not provide this 
functionality at the moment).  So the only chance I see is to introduce a new 
event type EVENT_SUBNODE_CHANGED. The properties of this event type can contain 
all available information about the change.

In the next major release we can extend the interface for the expression 
engines to work around this limitation.

 XMLConfiguration with setAutoSave(true) doesn't save if SubnodeConfiguration 
 is changed
 ---

 Key: CONFIGURATION-265
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-265
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.4
Reporter: Irina Fridkina
 Fix For: 1.5


 config.xml file
 conf
 parent-item
 sub-itemold_value/sub-item
 /parent-item
 /conf
 The problem can be reproduced as follows: 
  1 XMLConfiguration config = new XMLConfiguration(c:\\conf.xml); 
  2 config.setAutoSave(true) ;
  3 SubnodeConfiguration parentItemConfig = 
 config.configurationAt(parent-item); 
  4 parentItemConfig.setProperty(sub-item,new_value);
  5. System.out.println(config.getString(parent-item.sub-item);  // will 
 print new_value
  // if you look at the config.xml sub-item still has old_value
  // also if you try to do 
  5 XMLConfiguration config2 = new XMLConfiguration(c:\\conf.xml);
  6. System.out.println(config2.getString(parent-item.sub-item);  // will 
 print old_value

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


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



[jira] Commented: (POOL-94) GenericObjectPool allows checking in of previously checked in objects

2007-04-21 Thread Phil Steitz (JIRA)

[ 
https://issues.apache.org/jira/browse/POOL-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12490673
 ] 

Phil Steitz commented on POOL-94:
-

Another bad thing that can happen if an object instance is returned to the 
pool twice is that it will end up included in the idle object pool twice, so 
could get returned to two different clients on subsequent borrowObject calls.  
For example, with maxActive set to 3 on the pool, pool 1.1, 1.2 and 1.3 will 
all return object1 on the first and third call in the second set of 
borrowObjects below:

// Check  out three Foo things - assume factory makes them distinguishable
Foo object1 = (Foo) pool.borrowObject();
Foo object2 = (Foo) pool.borrowObject();
Foo object3 = (Foo) pool.borrowObject();

// Return two, but one of them twice
pool.returnObject(object1);
pool.returnObject(object2);
pool.returnObject(object1);

// Pool now thinks there are three available, and object1 is in idle instance 
pool twice
object1 = (Foo) pool.borrowObject();
object2 = (Foo) pool.borrowObject();
object3 = (Foo) pool.borrowObject();

At this point, object1 and object3 are the same.

The moral of the story here is that when using pool 1.x, user code must ensure 
that instances are not returned to the pool twice in sequence (i.e, without 
being borrowed again).  

 GenericObjectPool allows checking in of previously checked in objects
 -

 Key: POOL-94
 URL: https://issues.apache.org/jira/browse/POOL-94
 Project: Commons Pool
  Issue Type: New Feature
Affects Versions: 1.3
 Environment: JDK 1.4.2, web application running under Tomcat 5.0.25
Reporter: Tim McCollough
Priority: Minor

 I am using GenericObjectPool to store a pool of socket connections. While 
 debugging the application I noticed that the result of GetNumActive() was 
 becoming more and more negative, while the GetNumIldle() count was ever 
 increasing. Further debug showed that my application was returning the same 
 connection more than once and the GenericObjectPool implementation accepted 
 the return silently and decremented the active count and incremented the idle 
 count.
 I don't object to GenericObjectPool allowing multiple returns on the same 
 object, but the bookkeeping problem will lead to bad things happening in the 
 pool management code.
 I am investigating what it would take to fix GenericObjectPool but since I am 
 inexperienced in these commons projects I don't know what I should do from 
 here.

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


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



Re: [nightly build] configuration failed.

2007-04-21 Thread Phil Steitz

Looking at the old xdoc 1.8 jelly code, looks like what is failing
here is the report registration.  I don't know why exactly, but
upgrading the javadoc plugin to 1.8 works 4 me to fix this:

Index: project.xml
===
--- project.xml (revision 531127)
+++ project.xml (working copy)
@@ -502,6 +502,18 @@
  /comment
  /properties
/dependency
+dependency
+  groupIdmaven/groupId
+  artifactIdmaven-javadoc-plugin/artifactId
+  version1.8/version
+  urlhttp://maven.apache.org/maven-1.x/plugins/javadoc//url
+  typeplugin/type
+  properties
+  comment
+  lt;stronggt;Site Onlylt;/stronggt; - v1.8 (minimum)
+  /comment
+  /properties
+/dependency

  /dependencies

On 4/21/07, Phil Steitz [EMAIL PROTECTED] wrote:

Failed build logs:
http://vmbuild.apache.org/~commons/nightly/logs//20070421/configuration.log

-
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]