[jira] Created: (SCXML-49) SimpleSCXMLInvoker may miss transition to final state
SimpleSCXMLInvoker may miss transition to final state - Key: SCXML-49 URL: https://issues.apache.org/jira/browse/SCXML-49 Project: Commons SCXML Issue Type: Bug Affects Versions: 0.7 Reporter: Ingmar Kliche The current implementation of SimpleSCXMLInvoker assumes that only external events, handled by parentEvents(), may cause the child state machine to go move a final state. But in case where the invoked state machine moves to a final state directly (while executing the initial state, see example) the parent never receives an invoke.done. scxml xmlns=http://www.w3.org/2005/07/scxml version=1.0 initialstate=state1 state id=state1 onentry send event=foo/ /onentry transition event=foo target=state2 / /state state id=state2 final=true / /scxml -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JXPATH-93) Binary operators behaviour involving node-sets is incorrect
Binary operators behaviour involving node-sets is incorrect --- Key: JXPATH-93 URL: https://issues.apache.org/jira/browse/JXPATH-93 Project: Commons JXPath Issue Type: Bug Affects Versions: 1.2 Final Environment: 1.2, SVN version Reporter: Sergey Vladimirov According to XPath specification: If both objects to be compared are node-sets, then the comparison will be true if and only if there is a node in the first node-set and a node in the second node-set such that the result of performing the comparison on the string-values of the two nodes is true. If one object to be compared is a node-set and the other is a number, then the comparison will be true if and only if there is a node in the node-set such that the result of performing the comparison on the number to be compared and on the result of converting the string-value of that node to a number using the number function is true. But following example illustrates, that this is not a JXPath behaviour: JXPathContext pathContext = JXPathContext .newContext(DocumentBuilderFactory.newInstance() .newDocumentBuilder().parse( new InputSource(new StringReader( ?xml version=\1.0\ encoding=\UTF-8\?\r\n + doc/; Boolean result = (Boolean) pathContext.getValue(2.0 child1, Boolean.class); assertFalse(result.booleanValue()); child1 is not found - right operand node set is empty, but result is TRUE, instead of FALSE. Please, check greaterThan(), lesserThan(), etc methods of org.apache.xpath.objects.XObject for possible solution :) -- 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-275) ConfigurationUtils.append() doesn't merge list properties
[ https://issues.apache.org/jira/browse/CONFIGURATION-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511095 ] Oliver Heger commented on CONFIGURATION-275: Actually this seems to be a problem of AbstractConfiguration.addProperty(), which does not handle collection parameters properly when delimiter parsing is disabled. ConfigurationUtils.append() doesn't merge list properties - Key: CONFIGURATION-275 URL: https://issues.apache.org/jira/browse/CONFIGURATION-275 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.4 Reporter: Emmanuel Bourg Priority: Minor Fix For: 1.5 ConfigurationUtils.append() appends the list object instead of the list elements to the target list. If the list [X, Y] is appended to the list [A, B], the result is [A, B, [X, Y]] instead of [A, B, X, Y] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (DBCP-229) Track callers of active connections for debugging
Track callers of active connections for debugging - Key: DBCP-229 URL: https://issues.apache.org/jira/browse/DBCP-229 Project: Commons Dbcp Issue Type: New Feature Reporter: Armin Häberling Lately we got the following exception org.apache.commons.dbcp.SQLNestedException: Cannot get a connection, pool exhausted at org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:103) at org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:540) The reason for that was that some piece of code opened a connection, but never closed it. Tracking the active connections (and the callers of the getConnection method) would it make it easier to find such erroneous code. One possible approach would be to add the connection returned by BasicDataSource.getConnection together with the stacktrace in a Map holding all active connections. And removing the connection from the map during PoolableDataSource.close(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (SANDBOX-196) Compress - ZipArchive - unpack() : IOException while unpacking due to missing directories
Compress - ZipArchive - unpack() : IOException while unpacking due to missing
directories
-
Key: SANDBOX-196
URL: https://issues.apache.org/jira/browse/SANDBOX-196
Project: Commons Sandbox
Issue Type: Bug
Components: Compress
Affects Versions: Nightly Builds
Environment: Linux
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Reporter: Christian Scheid
In the current snapshot of the ZipArchive class of commons compress seems to be
an OS/VM-related problem with the unpack() method of ZipArchive.
I got an IOException using unpack() for a simple jar-archive.
I figured out that the files from the ZipEntries couldn't be created because of
missing parent directories.
I fixed the problem by including the usage of the forceMkdir() of the
commons-io FileUtils class in the unpack() method. In case you want to use my
fix:
// ... for every entry
File outFile = new File(fosString);
if (outFile.getParentFile() != null !outFile.getParentFile().exists()) {
FileUtils.forceMkdir(outFile.getParentFile());
}
FileOutputStream fos = new FileOutputStream(outFile);
// ... write to filestream
best regards,
chris
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (LOGGING-114) Silent Swallowing of NoClassDefFoundError
Silent Swallowing of NoClassDefFoundError - Key: LOGGING-114 URL: https://issues.apache.org/jira/browse/LOGGING-114 Project: Commons Logging Issue Type: Bug Affects Versions: 1.1.0 Environment: Various OSs, in combination with log4j 1.2.14. Reporter: Malcolm Cleaton Priority: Minor Hi. I'm using commons logging with log4j; my team ship a library which uses log4j, and some of our clients use it with commons-logging. If commons-logging is in its default configuration, and log4j is present but fails to load its configuration with an unhandled exception, the results are pretty nasty: - commons-logging silently swallows the exception and logs with something else. If diagnostics are turned on, the message is: Could not instantiate Log 'org.apache.commons.logging.impl.Log4JLogger' -- java.lang.reflect.InvocationTargetException: null - future attempts to use log4j directly get a pretty unhelpful error: java.lang.NoClassDefFoundError at org.apache.log4j.Logger.getLogger(Logger.java:117). I realise you're trying to deal with a very large number of cases in this code, but it does seem like something better could be done here. If nothing else is possible, at least recognising the InvocationTargetException and pulling out the target exception for the diagnostic log would have helped with tracking this one down. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (SCXML-49) SimpleSCXMLInvoker may miss transition to final state
[ https://issues.apache.org/jira/browse/SCXML-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rahul Akolkar updated SCXML-49: --- Fix Version/s: 0.7 Assignee: Rahul Akolkar Affects Version/s: (was: 0.7) 0.6 Setting fix version to next release. SimpleSCXMLInvoker may miss transition to final state - Key: SCXML-49 URL: https://issues.apache.org/jira/browse/SCXML-49 Project: Commons SCXML Issue Type: Bug Affects Versions: 0.6 Reporter: Ingmar Kliche Assignee: Rahul Akolkar Fix For: 0.7 The current implementation of SimpleSCXMLInvoker assumes that only external events, handled by parentEvents(), may cause the child state machine to go move a final state. But in case where the invoked state machine moves to a final state directly (while executing the initial state, see example) the parent never receives an invoke.done. scxml xmlns=http://www.w3.org/2005/07/scxml version=1.0 initialstate=state1 state id=state1 onentry send event=foo/ /onentry transition event=foo target=state2 / /state state id=state2 final=true / /scxml -- 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: [httpclient] Remove from trunks-proper? (was: svn commit: r553886)
If there are no objections (say within three days), I will remove httpclient from the externals on trunks-proper as well. -Rahul On 7/6/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: rolandw Date: Fri Jul 6 07:12:06 2007 New Revision: 553886 URL: http://svn.apache.org/viewvc?view=revrev=553886 Log: HttpClient trunk has moved to http://svn.apache.org/repos/asf/jakarta/httpcomponents/oac.hc3x/trunk/ Removed: jakarta/commons/proper/httpclient/trunk/docs/ jakarta/commons/proper/httpclient/trunk/src/ jakarta/commons/proper/httpclient/trunk/xdocs/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (FILEUPLOAD-135) InputStream created with Streaming API returns EOF on first read() for short files uploaded from FireFox over HTTPS
[ https://issues.apache.org/jira/browse/FILEUPLOAD-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511187 ] Rob Slifka commented on FILEUPLOAD-135: --- Many thanks Jochen! I see that another has verified the fix in FILEUPLOAD-138. Any idea when we'll see 1.2.1 released? InputStream created with Streaming API returns EOF on first read() for short files uploaded from FireFox over HTTPS --- Key: FILEUPLOAD-135 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-135 Project: Commons FileUpload Issue Type: Bug Affects Versions: 1.2, 1.2.1 Environment: Windows XP Browser: Firefox 1.5.0.11 Protocol: HTTPS Reporter: Alexander Sova Assignee: Jochen Wiedmann Fix For: 1.2.1 Attachments: commons-fileupload-1.1-bug-short-file-eof.patch, commons-fileupload-1.2-bug-short-file-eof.patch, FILEUPLOAD135.patch This problem happens only with files shorer then boundary string generated by browser and only with Firefox using HTTPS protocol. For some reason in this particular environment inputStream.read() in MultipartStream.ItemInputStream.makeAvailable() reads not whole HTTP response body, but only file content before boundary string. I've created a patch fixing this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r554746 - in /jakarta/commons/proper/configuration/trunk: src/java/org/apache/commons/configuration/HierarchicalConfiguration.java xdocs/changes.xml
Author: oheger
Date: Mon Jul 9 12:37:37 2007
New Revision: 554746
URL: http://svn.apache.org/viewvc?view=revrev=554746
Log:
CONFIGURATION-282: Initialize default expression engine for
HierarchicalConfiguration lazily if it is null. This should avoid NPEs after
redeployment.
Modified:
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/HierarchicalConfiguration.java
jakarta/commons/proper/configuration/trunk/xdocs/changes.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=554746r1=554745r2=554746
==
---
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
Mon Jul 9 12:37:37 2007
@@ -151,7 +151,7 @@
private static final long serialVersionUID = 3373812230395363192L;
/** Stores the default expression engine to be used for new objects.*/
-private static ExpressionEngine defaultExpressionEngine = new
DefaultExpressionEngine();
+private static ExpressionEngine defaultExpressionEngine;
/** Stores the root node of this configuration. This field is required for
* backwards compatibility only.
@@ -258,8 +258,12 @@
* @return the default expression engine
* @since 1.3
*/
-public static ExpressionEngine getDefaultExpressionEngine()
+public static synchronized ExpressionEngine getDefaultExpressionEngine()
{
+if (defaultExpressionEngine == null)
+{
+defaultExpressionEngine = new DefaultExpressionEngine();
+}
return defaultExpressionEngine;
}
@@ -272,7 +276,7 @@
* @param engine the new default expression engine
* @since 1.3
*/
-public static void setDefaultExpressionEngine(ExpressionEngine engine)
+public static synchronized void
setDefaultExpressionEngine(ExpressionEngine engine)
{
if (engine == null)
{
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=554746r1=554745r2=554746
==
--- jakarta/commons/proper/configuration/trunk/xdocs/changes.xml (original)
+++ jakarta/commons/proper/configuration/trunk/xdocs/changes.xml Mon Jul 9
12:37:37 2007
@@ -23,6 +23,11 @@
body
release version=1.5-SNAPSHOT date=in SVN description=
+ action dev=oheger type=fix issue=CONFIGURATION-282
+The default expression engine used by HierarchicalConfiguration
+instances is now lazily initialized. This avoids NullPointerExceptions
+in certain server environments after a redeploy.
+ /action
action dev=oheger type=fix issue=CONFIGURATION-281
Cycles in the JNDI tree no longer cause a stack overflow in
JNDIConfiguration.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-282) NPE in HierarchicalConfiguration.fetchNodeList
[ https://issues.apache.org/jira/browse/CONFIGURATION-282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511235 ] Oliver Heger commented on CONFIGURATION-282: A fix was committed that initializes the default expression engine every time if it is null. Can you please check whether this solves your problem? Unfortunately I have no idea how to write a unit test that demonstrates the problem. However because the defaultExpressionEngine field is now null at the beginning, code coverage should be complete. There is now some additional overhead because of the required synchronization of the static getDefaultExpressionEngine() method, which also gets called if no specific expression engine is set for a configuration instance. This could be avoided if the default expression engine is fetched once in the constructor of HierarchicalConfiguration and copied into the member field for the local expression engine. The drawback is that this could break existing code that relies on the fact that changing the default expression engine immediately impacts all configuration instances that have no specific expression engine set. So I would prefer making this change only in a major release. NPE in HierarchicalConfiguration.fetchNodeList -- Key: CONFIGURATION-282 URL: https://issues.apache.org/jira/browse/CONFIGURATION-282 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.4 Environment: Linux, Java 1.5 Reporter: Dennis Kieselhorst Assignee: Oliver Heger java.lang.NullPointerException at org.apache.commons.configuration.HierarchicalConfiguration.fetchNodeList(HierarchicalConfiguration.java:721) at org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.fetchNodeList(AbstractHierarchicalFileConfiguration.java:338) at org.apache.commons.configuration.HierarchicalConfiguration.getProperty(HierarchicalConfiguration.java:284) at org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.getProperty(AbstractHierarchicalFileConfiguration.java:319) at org.apache.commons.configuration.AbstractConfiguration.resolveContainerStore(AbstractConfiguration.java:1222) at org.apache.commons.configuration.AbstractConfiguration.getBoolean(AbstractConfiguration.java:667) at org.apache.commons.configuration.AbstractConfiguration.getBoolean(AbstractConfiguration.java:633) java.lang.NullPointerException at org.apache.commons.configuration.HierarchicalConfiguration.fetchNodeList(HierarchicalConfiguration.java:721) at org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.fetchNodeList(AbstractHierarchicalFileConfiguration.java:338) at org.apache.commons.configuration.HierarchicalConfiguration.getProperty(HierarchicalConfiguration.java:284) at org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.getProperty(AbstractHierarchicalFileConfiguration.java:319) at org.apache.commons.configuration.AbstractConfiguration.resolveContainerStore(AbstractConfiguration.java:1222) at org.apache.commons.configuration.AbstractConfiguration.getString(AbstractConfiguration.java:1097) at org.apache.commons.configuration.AbstractConfiguration.getString(AbstractConfiguration.java:1077) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONFIGURATION-282) NPE in HierarchicalConfiguration.fetchNodeList after redeployment
[ https://issues.apache.org/jira/browse/CONFIGURATION-282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger updated CONFIGURATION-282: --- Fix Version/s: 1.5 Summary: NPE in HierarchicalConfiguration.fetchNodeList after redeployment (was: NPE in HierarchicalConfiguration.fetchNodeList) NPE in HierarchicalConfiguration.fetchNodeList after redeployment - Key: CONFIGURATION-282 URL: https://issues.apache.org/jira/browse/CONFIGURATION-282 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.4 Environment: Linux, Java 1.5 Reporter: Dennis Kieselhorst Assignee: Oliver Heger Fix For: 1.5 java.lang.NullPointerException at org.apache.commons.configuration.HierarchicalConfiguration.fetchNodeList(HierarchicalConfiguration.java:721) at org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.fetchNodeList(AbstractHierarchicalFileConfiguration.java:338) at org.apache.commons.configuration.HierarchicalConfiguration.getProperty(HierarchicalConfiguration.java:284) at org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.getProperty(AbstractHierarchicalFileConfiguration.java:319) at org.apache.commons.configuration.AbstractConfiguration.resolveContainerStore(AbstractConfiguration.java:1222) at org.apache.commons.configuration.AbstractConfiguration.getBoolean(AbstractConfiguration.java:667) at org.apache.commons.configuration.AbstractConfiguration.getBoolean(AbstractConfiguration.java:633) java.lang.NullPointerException at org.apache.commons.configuration.HierarchicalConfiguration.fetchNodeList(HierarchicalConfiguration.java:721) at org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.fetchNodeList(AbstractHierarchicalFileConfiguration.java:338) at org.apache.commons.configuration.HierarchicalConfiguration.getProperty(HierarchicalConfiguration.java:284) at org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.getProperty(AbstractHierarchicalFileConfiguration.java:319) at org.apache.commons.configuration.AbstractConfiguration.resolveContainerStore(AbstractConfiguration.java:1222) at org.apache.commons.configuration.AbstractConfiguration.getString(AbstractConfiguration.java:1097) at org.apache.commons.configuration.AbstractConfiguration.getString(AbstractConfiguration.java:1077) -- 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: r554757 - in /jakarta/commons/proper/configuration/trunk: src/java/org/apache/commons/configuration/AbstractConfiguration.java src/test/org/apache/commons/configuration/TestAbstractConfigu
Author: oheger
Date: Mon Jul 9 13:34:27 2007
New Revision: 554757
URL: http://svn.apache.org/viewvc?view=revrev=554757
Log:
CONFIGURATION-275: AbstractConfiguration.addProperty() now correctly deals with
list and array properties if delimiter parsing is disabled
Modified:
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/AbstractConfiguration.java
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestAbstractConfigurationBasicFeatures.java
jakarta/commons/proper/configuration/trunk/xdocs/changes.xml
Modified:
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/AbstractConfiguration.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/AbstractConfiguration.java?view=diffrev=554757r1=554756r2=554757
==
---
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/AbstractConfiguration.java
(original)
+++
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/AbstractConfiguration.java
Mon Jul 9 13:34:27 2007
@@ -117,6 +117,13 @@
/** end token */
protected static final String END_TOKEN = };
+/**
+ * Constant for the disabled list delimiter. This character is passed to
the
+ * list parsing methods if delimiter parsing is disabled. So this character
+ * should not occur in string property values.
+ */
+private static final char DISABLED_DELIMITER = '\0';
+
/** The default value for listDelimiter */
private static char defaultListDelimiter = ',';
@@ -381,17 +388,12 @@
{
fireEvent(EVENT_ADD_PROPERTY, key, value, true);
-if (!isDelimiterParsingDisabled())
-{
-Iterator it = PropertyConverter.toIterator(value,
getListDelimiter());
-while (it.hasNext())
-{
-addPropertyDirect(key, it.next());
-}
-}
-else
+Iterator it = PropertyConverter.toIterator(value,
+isDelimiterParsingDisabled() ? DISABLED_DELIMITER
+: getListDelimiter());
+while (it.hasNext())
{
-addPropertyDirect(key, value);
+addPropertyDirect(key, it.next());
}
fireEvent(EVENT_ADD_PROPERTY, key, value, false);
@@ -399,7 +401,7 @@
/**
* Adds a key/value pair to the Configuration. Override this method to
- * provide write acces to underlying Configuration store.
+ * provide write access to underlying Configuration store.
*
* @param key key to use for mapping
* @param value object to store
Modified:
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestAbstractConfigurationBasicFeatures.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestAbstractConfigurationBasicFeatures.java?view=diffrev=554757r1=554756r2=554757
==
---
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestAbstractConfigurationBasicFeatures.java
(original)
+++
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestAbstractConfigurationBasicFeatures.java
Mon Jul 9 13:34:27 2007
@@ -20,6 +20,7 @@
import java.util.Arrays;
import java.util.Collection;
import java.util.Iterator;
+import java.util.List;
import org.apache.commons.collections.CollectionUtils;
@@ -76,6 +77,50 @@
Wrong interpolated value,
${DB2UNIVERSAL_JDBC_DRIVER_PATH}/db2jcc.jar,${DB2UNIVERSAL_JDBC_DRIVER_PATH}/db2jcc_license_cu.jar,
config.getString(mypath));
+}
+
+/**
+ * Tests adding list properties. The single elements of the list should be
+ * added.
+ */
+public void testAddPropertyList()
+{
+checkAddListProperty(new TestConfigurationImpl(
+new PropertiesConfiguration()));
+}
+
+/**
+ * Tests adding list properties when delimiter parsing is disabled.
+ */
+public void testAddPropertyListNoDelimiterParsing()
+{
+AbstractConfiguration config = new TestConfigurationImpl(
+new PropertiesConfiguration());
+config.setDelimiterParsingDisabled(true);
+checkAddListProperty(config);
+}
+
+/**
+ * Helper method for adding properties with multiple values.
+ *
+ * @param config the configuration to be used for testing
+ */
+private void checkAddListProperty(AbstractConfiguration config)
+{
+config.addProperty(test, value1);
+Object[] lstValues1 = new Object[]
+{ value2, value3 };
+Object[] lstValues2 = new Object[]
[jira] Resolved: (CONFIGURATION-275) ConfigurationUtils.append() doesn't merge list properties
[ https://issues.apache.org/jira/browse/CONFIGURATION-275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-275. Resolution: Fixed A fix was applied. addProperty() now always obtains an iterator for the property to add using PropertyConverter.toIterator(). If delimiter parsing is disabled, a null delimiter is passed in, so that no splitting is performed. ConfigurationUtils.append() doesn't merge list properties - Key: CONFIGURATION-275 URL: https://issues.apache.org/jira/browse/CONFIGURATION-275 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.4 Reporter: Emmanuel Bourg Assignee: Oliver Heger Priority: Minor Fix For: 1.5 ConfigurationUtils.append() appends the list object instead of the list elements to the target list. If the list [X, Y] is appended to the list [A, B], the result is [A, B, [X, Y]] instead of [A, B, X, Y] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (COLLECTIONS-259) TransformerClosure should implement Transformer and allow extension.
TransformerClosure should implement Transformer and allow extension.
Key: COLLECTIONS-259
URL: https://issues.apache.org/jira/browse/COLLECTIONS-259
Project: Commons Collections
Issue Type: Improvement
Components: Functor
Affects Versions: 3.2
Reporter: Stephen Kestle
Priority: Minor
Fix For: 3.3, Generics
TransformerClosure currently decorates a transformer. However, in the
interests of non-verbose code, it makes sense to be able to subclass it for a
class that implements both interfaces.
I propose the addition of the following constructor and method
protected TransformerClosure(){
iTransformer = this;
}
public O transform(I in){
return iTransformer.transform();
}
--
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: [functor] revival WAS Functor Users / Project Management?
Hello, I'm curious if the vote was ever taken, and if so, what was the result ? I'd very much like to see Functor come alive again and start taking advantage of the benefits of Java 5/6. Alex Marshall Software Developer Email: [EMAIL PROTECTED] MSN Messenger: [EMAIL PROTECTED] ICQ:137350791 Skype username: alex.marshall Office: 1-888-286-2010 Ext 229 Fax:1-780-484-0538 CONFIDENTIAL: This message, including any attachments, may contain confidential and/or privileged information, which is intended solely for the use of the addressee(s). Any unauthorized review, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please contact the sender and destroy all copies of the original message. Rahul Akolkar wrote: On 5/30/07, Matt Benson [EMAIL PROTECTED] wrote: snip/ Right, I meant whether the vote should be held as in are there any reasons why reviving [functor] would be simply out of the question? I wasn't implying any desire to circumvent established protocols. :) snap/ Not sure if there is an established protocol :-) (other than that bit on the site, since dormancy has sort of been a one-way street -- I'm for voting). -Rahul -Matt - 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]
New M2 snapshots use org.apache.commons?
For development of new releases, should the commons-* folders be forgone and use org.apache.commons now? Thanks, Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New M2 snapshots use org.apache.commons?
On 7/9/07, Paul Benedict [EMAIL PROTECTED] wrote: For development of new releases, should the commons-* folders be forgone and use org.apache.commons now? Check the list archives for some past discussion... it has to be handled carefully with old releases relocated in the central repository, or downstream users will be adversely affected. Nabble turns up a few relevant posts: http://www.nabble.com/forum/Search.jtp?forum=317local=yquery=commons+maven+groupid -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (VALIDATOR-233) Update location of dojo compressor library
Update location of dojo compressor library -- Key: VALIDATOR-233 URL: https://issues.apache.org/jira/browse/VALIDATOR-233 Project: Commons Validator Issue Type: Task Components: JavaScript Affects Versions: 1.4 Reporter: Paul Benedict Fix For: 1.4 build-javascript.xml no longer has a valid URL to the compressor library. It is now located at: http://svn.dojotoolkit.org/dojo/trunk/buildscripts/lib/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (VALIDATOR-234) Create 1.4 DTD
Create 1.4 DTD -- Key: VALIDATOR-234 URL: https://issues.apache.org/jira/browse/VALIDATOR-234 Project: Commons Validator Issue Type: Task Components: Framework Affects Versions: 1.4 Reporter: Paul Benedict Fix For: 1.4 Create 1.4 DTD -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VALIDATOR-232) Add script attribute to control script generation
[ https://issues.apache.org/jira/browse/VALIDATOR-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Benedict updated VALIDATOR-232: Attachment: VALIDATOR-232.patch Added new scripting property to Field. I chose the term scripting over script because that's the typical language. Also, I wanted to reserve script in case one day we allow alternative pluggable scripts on a field basis. Add script attribute to control script generation - Key: VALIDATOR-232 URL: https://issues.apache.org/jira/browse/VALIDATOR-232 Project: Commons Validator Issue Type: New Feature Components: Framework Reporter: Paul Benedict Priority: Minor Fix For: 1.4 Attachments: VALIDATOR-232.patch Add a script=true|false attribute to field to control whether JavaScript should be generated. Also see: https://issues.apache.org/struts/browse/STR-1888 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VALIDATOR-232) Add script attribute to control script generation
[ https://issues.apache.org/jira/browse/VALIDATOR-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Benedict updated VALIDATOR-232: Attachment: VALIDATOR-232.dtd.patch Attaching patch for the 1.4 DTD. Once the DTD is cloned and checked in, this adds the scripting attribute to field Add script attribute to control script generation - Key: VALIDATOR-232 URL: https://issues.apache.org/jira/browse/VALIDATOR-232 Project: Commons Validator Issue Type: New Feature Components: Framework Reporter: Paul Benedict Priority: Minor Fix For: 1.4 Attachments: VALIDATOR-232.dtd.patch, VALIDATOR-232.patch Add a script=true|false attribute to field to control whether JavaScript should be generated. Also see: https://issues.apache.org/struts/browse/STR-1888 -- 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]
