[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_12489027 ] Anselm Kruis commented on CONFIGURATION-249: Hi Emmanuel, Besides plain file:-URLs, I'll write to a fgfile:-URL. Unfortunately, fgfile is an URL schema specific to a closed source product: flowGuide from science+computing. The fgfile-URL is an extention to the usual file URL, that adds some metadata about the file. But it is also possible to write to ftp or http or any other writable schema you plug into the java runtime. Of course this makes testing the non file: case a little bit complicated: you need a suitable ftp or http server first, or you need your own URL-handler classes. Best Regards Anselm --- Dipl. Phys. Anselm Kruis science + computing ag Senior Solutions Engineer Ingolst�dter Str. 22 email [EMAIL PROTECTED] 80807 M�nchen, Germany phone +49 89 356386 874www.science-computing.de fax +49 89 356386 737 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.5 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. - 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: [configuration] Re: [nightly build] configuration failed.
Phil Steitz a écrit : On 4/15/07, Emmanuel Bourg [EMAIL PROTECTED] wrote: I have the same version of Maven and the build works fine with the xdoc plugin 1.8. What is wrong ? Here is what I get from maven clean xdoc on vmbuild for configuration: File.. /home/psteitz/.maven/cache/maven-xdoc-plugin-1.8/plugin.jelly Element... attainGoal Line.. 687 Column 48 No goal [xdoc:init-i18n] It is using the 1.8 version of the xdoc plugin. Are you using maven 1.0.2, or maven 1.1? I have Maven 1.0.2 on Windows, with the xdoc 1.8 plugin in the Maven plugins directory. I downgraded the version of this plugin in the project.xml file from 1.9.2 to 1.8 to change the way the titles of the pages are generated. Could this be an issue with the Maven cache ? Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36185] - [cli] supporting options without a short option
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36185. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36185 --- Additional Comments From [EMAIL PROTECTED] 2007-04-16 01:31 --- (In reply to comment #2) *** Bug 36295 has been marked as a duplicate of this bug. *** any news on this bug ? exists a patch? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - 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_12489044 ] Emmanuel Bourg commented on CONFIGURATION-249: -- Thank you Anselm, I'll try to build a test case with a FTP server. 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.5 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. - 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-217) ding
ding Key: DBCP-217 URL: https://issues.apache.org/jira/browse/DBCP-217 Project: Commons Dbcp Issue Type: Bug Reporter: Sebastian Mancke -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (DBCP-217) Closing of underlaying connection instead of the PoolGuardConnectionWrapper
[ https://issues.apache.org/jira/browse/DBCP-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Mancke updated DBCP-217: -- Description: Is state: If I obtain the Connection of a Statement (stmt.getConnection()), created with dbcp, the returned Object is the underlaying pooled connection. Closing this connection multiple times may close the connection of another process. It should be: The Wrapper over the connection PoolGuardConnectionWrapper should be returned instead. Affects Version/s: 1.2.2 Summary: Closing of underlaying connection instead of the PoolGuardConnectionWrapper (was: ding) Closing of underlaying connection instead of the PoolGuardConnectionWrapper --- Key: DBCP-217 URL: https://issues.apache.org/jira/browse/DBCP-217 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.2.2 Reporter: Sebastian Mancke Is state: If I obtain the Connection of a Statement (stmt.getConnection()), created with dbcp, the returned Object is the underlaying pooled connection. Closing this connection multiple times may close the connection of another process. It should be: The Wrapper over the connection PoolGuardConnectionWrapper should be returned instead. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (DBCP-217) Closing of underlaying connection instead of the PoolGuardConnectionWrapper
[ https://issues.apache.org/jira/browse/DBCP-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Mancke updated DBCP-217: -- Attachment: connectionCloseFix.patch This patch sets the wrapper (instance of PoolGuardConnectionWrapper) as the connection of every created statement. Closing of underlaying connection instead of the PoolGuardConnectionWrapper --- Key: DBCP-217 URL: https://issues.apache.org/jira/browse/DBCP-217 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.2.2 Reporter: Sebastian Mancke Attachments: connectionCloseFix.patch Is state: If I obtain the Connection of a Statement (stmt.getConnection()), created with dbcp, the returned Object is the underlaying pooled connection. Closing this connection multiple times may close the connection of another process. It should be: The Wrapper over the connection PoolGuardConnectionWrapper should be returned instead. -- 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]
[nightly build] configuration failed.
Failed build logs: http://vmbuild.apache.org/~commons/nightly/logs//20070416/configuration.log - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r529194 - in /jakarta/commons/proper/configuration/trunk: src/java/org/apache/commons/configuration/ src/java/org/apache/commons/configuration/plist/ src/test/org/apache/commons/configurat
Author: ebourg
Date: Mon Apr 16 03:40:42 2007
New Revision: 529194
URL: http://svn.apache.org/viewvc?view=revrev=529194
Log:
AbstractFileConfiguration now supports saving to non file URLs
(CONFIGURATION-249)
Fixed a typo on the overview page
Modified:
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/AbstractFileConfiguration.java
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/FileConfiguration.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/TestFileConfiguration.java
jakarta/commons/proper/configuration/trunk/xdocs/changes.xml
jakarta/commons/proper/configuration/trunk/xdocs/overview.xml
Modified:
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/AbstractFileConfiguration.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/AbstractFileConfiguration.java?view=diffrev=529194r1=529193r2=529194
==
---
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/AbstractFileConfiguration.java
(original)
+++
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/AbstractFileConfiguration.java
Mon Apr 16 03:40:42 2007
@@ -27,8 +27,10 @@
import java.io.Reader;
import java.io.UnsupportedEncodingException;
import java.io.Writer;
+import java.net.HttpURLConnection;
import java.net.MalformedURLException;
import java.net.URL;
+import java.net.URLConnection;
import java.util.Iterator;
import org.apache.commons.configuration.reloading.InvariantReloadingStrategy;
@@ -409,7 +411,7 @@
}
/**
- * Save the configuration to the specified URL if it's a file URL.
+ * Save the configuration to the specified URL.
* This doesn't change the source of the configuration, use setURL()
* if you need it.
*
@@ -419,6 +421,8 @@
*/
public void save(URL url) throws ConfigurationException
{
+// file URLs have to be converted to Files since FileURLConnection is
+// read only
(http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4191800)
File file = ConfigurationUtils.fileFromURL(url);
if (file != null)
{
@@ -426,7 +430,35 @@
}
else
{
-throw new ConfigurationException(Could not save to URL + url);
+// for non file URLs save through an URLConnection
+try
+{
+URLConnection connection = url.openConnection();
+connection.setDoOutput(true);
+
+// use the PUT method for http URLs
+if (connection instanceof HttpURLConnection)
+{
+HttpURLConnection conn = (HttpURLConnection) connection;
+conn.setRequestMethod(PUT);
+}
+
+save(connection.getOutputStream());
+
+// check the response code for http URLs and throw an
exception if an error occured
+if (connection instanceof HttpURLConnection)
+{
+HttpURLConnection conn = (HttpURLConnection) connection;
+if (conn.getResponseCode() =
HttpURLConnection.HTTP_BAD_REQUEST)
+{
+throw new IOException(HTTP Error +
conn.getResponseCode() + + conn.getResponseMessage());
+}
+}
+}
+catch (IOException e)
+{
+throw new ConfigurationException(Could not save to URL +
url + : + e.getMessage());
+}
}
}
@@ -647,8 +679,7 @@
{
try
{
-path = ConfigurationUtils.getURL(getBasePath(),
-getFileName()).getPath();
+path = ConfigurationUtils.getURL(getBasePath(),
getFileName()).getPath();
}
catch (MalformedURLException e)
{
@@ -877,8 +908,7 @@
* @param propValue the value of the property
* @param before the before update flag
*/
-protected void fireEvent(int type, String propName, Object propValue,
-boolean before)
+protected void fireEvent(int type, String propName, Object propValue,
boolean before)
{
enterNoReload();
try
@@ -959,8 +989,7 @@
*/
public Object clone()
{
-AbstractFileConfiguration copy = (AbstractFileConfiguration) super
-.clone();
+AbstractFileConfiguration copy = (AbstractFileConfiguration)
super.clone();
copy.setBasePath(null);
[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_12489073 ] Emmanuel Bourg commented on CONFIGURATION-249: -- I changed AbstractFileConfiguration.save(URL) to allow non file URLs, could you give it a try Anselm ? It worked fine with a FTP server, I have still to build a test case demonstrating this. For HTTP URLs I had to force the PUT method since the POST method is used by default once setDoOutput(true) is called. I haven't tested with a http server allowing PUT requests yet. 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.5 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. - 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: r529210 - in /jakarta/commons/proper/configuration/trunk/src: java/org/apache/commons/configuration/DatabaseConfiguration.java test/org/apache/commons/configuration/TestDatabaseConfigurati
Author: ebourg
Date: Mon Apr 16 04:54:11 2007
New Revision: 529210
URL: http://svn.apache.org/viewvc?view=revrev=529210
Log:
Improved the javadoc for DatabaseConfiguration
Made getConnection() package private since it's only used for testing
Modified:
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/DatabaseConfiguration.java
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestDatabaseConfiguration.java
Modified:
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/DatabaseConfiguration.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/DatabaseConfiguration.java?view=diffrev=529210r1=529209r2=529210
==
---
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/DatabaseConfiguration.java
(original)
+++
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/DatabaseConfiguration.java
Mon Apr 16 04:54:11 2007
@@ -33,11 +33,51 @@
import org.apache.commons.logging.LogFactory;
/**
- * Configuration stored in a database.
+ * Configuration stored in a database. The properties are retrieved from a
+ * table containing at least one column for the keys, and one column for the
+ * values. It's possible to store several configurations in the same table by
+ * adding a column containing the name of the configuration. The name of the
+ * table and the columns is specified in the constructor.
+ *
+ * h4Example 1 - One configuration per table/h4
+ *
+ * pre
+ * CREATE TABLE myconfig (
+ * `key` VARCHAR NOT NULL PRIMARY KEY,
+ * `value` VARCHAR
+ * );
+ *
+ * INSERT INTO myconfig (key, value) VALUES ('foo', 'bar');
+ *
+ *
+ * Configuration config = new DatabaseConfiguration(datasource, myconfig,
key, value);
+ * String value = config.getString(foo);
+ * /pre
+ *
+ * h4Example 2 - Multiple configurations per table/h4
+ *
+ * pre
+ * CREATE TABLE myconfigs (
+ * `name` VARCHAR NOT NULL,
+ * `key` VARCHAR NOT NULL,
+ * `value` VARCHAR,
+ * CONSTRAINT sys_pk_myconfigs PRIMARY KEY (`name`, `key`)
+ * );
+ *
+ * INSERT INTO myconfigs (name, key, value) VALUES ('config1', 'key1',
'value1');
+ * INSERT INTO myconfigs (name, key, value) VALUES ('config2', 'key2',
'value2');
+ *
+ *
+ * Configuration config1 = new DatabaseConfiguration(datasource, myconfigs,
name, key, value, config1);
+ * String value1 = conf.getString(key1);
+ *
+ * Configuration config2 = new DatabaseConfiguration(datasource, myconfigs,
name, key, value, config2);
+ * String value2 = conf.getString(key2);
+ * /pre
*
* @since 1.0
*
- * @author Emmanuel Bourg
+ * @author a href=mailto:[EMAIL PROTECTED]Emmanuel Bourg/a
* @version $Revision$, $Date$
*/
public class DatabaseConfiguration extends AbstractConfiguration
@@ -521,7 +561,7 @@
* @throws SQLException if an error occurs
* @since 1.4
*/
-protected Connection getConnection() throws SQLException
+Connection getConnection() throws SQLException
{
return getDatasource().getConnection();
}
Modified:
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestDatabaseConfiguration.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestDatabaseConfiguration.java?view=diffrev=529210r1=529209r2=529210
==
---
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestDatabaseConfiguration.java
(original)
+++
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestDatabaseConfiguration.java
Mon Apr 16 04:54:11 2007
@@ -133,8 +133,7 @@
*/
private PotentialErrorDatabaseConfiguration setUpConfig()
{
-return new PotentialErrorDatabaseConfiguration(datasource, TABLE,
-COL_KEY, COL_VALUE);
+return new PotentialErrorDatabaseConfiguration(datasource, TABLE,
COL_KEY, COL_VALUE);
}
/**
@@ -145,8 +144,7 @@
*/
private DatabaseConfiguration setUpMultiConfig()
{
-return new DatabaseConfiguration(datasource, TABLE_MULTI, COL_NAME,
-COL_KEY, COL_VALUE, CONFIG_NAME);
+return new DatabaseConfiguration(datasource, TABLE_MULTI, COL_NAME,
COL_KEY, COL_VALUE, CONFIG_NAME);
}
/**
@@ -157,8 +155,7 @@
private void setUpErrorListener(PotentialErrorDatabaseConfiguration config)
{
// remove log listener to avoid exception longs
-config.removeErrorListener((ConfigurationErrorListener) config
-.getErrorListeners().iterator().next());
+config.removeErrorListener((ConfigurationErrorListener)
DO NOT REPLY [Bug 36185] - [cli] supporting options without a short option
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36185. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36185 --- Additional Comments From [EMAIL PROTECTED] 2007-04-16 06:07 --- It's now at: https://issues.apache.org/jira/browse/CLI-109 Andrew Shirley added a comment that CLI2 fixes it, so unless it's an easy CLI1 fix I imagine it will be closed WONTFIX when/if activity starts on CLI again. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-117) EndianUtils.readSwappedUnsignedInteger() may return a negative number
[ https://issues.apache.org/jira/browse/IO-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489108 ] Henri Yandell commented on IO-117: -- Do you have any particular examples/test cases in mind where there are problems, or is this theoretical? EndianUtils.readSwappedUnsignedInteger() may return a negative number - Key: IO-117 URL: https://issues.apache.org/jira/browse/IO-117 Project: Commons IO Issue Type: Bug Affects Versions: 1.3.1 Reporter: Hiroshi Ikeda Methods about reading unsigned-integer in class EndianUtils may return a negative number, due to casting int to long. Calculations with operator etc. are under integer in these methods so its results are integer, then implicit casting the results to long keeps its positive/negative sign. -- 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: (SCXML-44) Interface consistency: State.getIsFinal and State.setIsFinal
Interface consistency: State.getIsFinal and State.setIsFinal Key: SCXML-44 URL: https://issues.apache.org/jira/browse/SCXML-44 Project: Commons SCXML Issue Type: Improvement Affects Versions: 0.6 Reporter: Jörg Weinmann Priority: Trivial Getter and setter method for boolean isFinal is inconsistent to similiar getter and setter methods in the class. I would have expected: State.isFinal() and State.setFinal(). Compare to isDone(), isSimple(), isDone(), setDone(). -- 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-248) TrackingCollection
TrackingCollection -- Key: COLLECTIONS-248 URL: https://issues.apache.org/jira/browse/COLLECTIONS-248 Project: Commons Collections Issue Type: New Feature Components: Collection Reporter: Nicolas Marchildon Attachments: CollectionLoader.java, TrackingCollection.java, TrackingCollectionTest.java Sometimes you need to keep track of what was added and what was removed from a collection, and that is what we created TrackingCollection for. Additionally, since we were implementing lazy-loading of collections of persistent objects, we introduced a CollectionLoader that is used by the TrackingCollection when it has to access all of its elements. It is still possible however to use the TrackingCollection without a loader, and it will simply start empty and be considered loaded. Sherpa Solutions is offering the Apache Software Foundation the attached source code, to be distributed by the projet under the Apache License terms. -- 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: (COLLECTIONS-248) TrackingCollection
[ https://issues.apache.org/jira/browse/COLLECTIONS-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Marchildon updated COLLECTIONS-248: --- Attachment: CollectionLoader.java TrackingCollection -- Key: COLLECTIONS-248 URL: https://issues.apache.org/jira/browse/COLLECTIONS-248 Project: Commons Collections Issue Type: New Feature Components: Collection Reporter: Nicolas Marchildon Attachments: CollectionLoader.java, TrackingCollection.java, TrackingCollectionTest.java Sometimes you need to keep track of what was added and what was removed from a collection, and that is what we created TrackingCollection for. Additionally, since we were implementing lazy-loading of collections of persistent objects, we introduced a CollectionLoader that is used by the TrackingCollection when it has to access all of its elements. It is still possible however to use the TrackingCollection without a loader, and it will simply start empty and be considered loaded. Sherpa Solutions is offering the Apache Software Foundation the attached source code, to be distributed by the projet under the Apache License terms. -- 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: (COLLECTIONS-248) TrackingCollection
[ https://issues.apache.org/jira/browse/COLLECTIONS-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Marchildon updated COLLECTIONS-248: --- Attachment: TrackingCollection.java TrackingCollection -- Key: COLLECTIONS-248 URL: https://issues.apache.org/jira/browse/COLLECTIONS-248 Project: Commons Collections Issue Type: New Feature Components: Collection Reporter: Nicolas Marchildon Attachments: CollectionLoader.java, TrackingCollection.java, TrackingCollectionTest.java Sometimes you need to keep track of what was added and what was removed from a collection, and that is what we created TrackingCollection for. Additionally, since we were implementing lazy-loading of collections of persistent objects, we introduced a CollectionLoader that is used by the TrackingCollection when it has to access all of its elements. It is still possible however to use the TrackingCollection without a loader, and it will simply start empty and be considered loaded. Sherpa Solutions is offering the Apache Software Foundation the attached source code, to be distributed by the projet under the Apache License terms. -- 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: (COLLECTIONS-248) TrackingCollection
[ https://issues.apache.org/jira/browse/COLLECTIONS-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Marchildon updated COLLECTIONS-248: --- Attachment: TrackingCollectionTest.java TrackingCollection -- Key: COLLECTIONS-248 URL: https://issues.apache.org/jira/browse/COLLECTIONS-248 Project: Commons Collections Issue Type: New Feature Components: Collection Reporter: Nicolas Marchildon Attachments: CollectionLoader.java, TrackingCollection.java, TrackingCollectionTest.java Sometimes you need to keep track of what was added and what was removed from a collection, and that is what we created TrackingCollection for. Additionally, since we were implementing lazy-loading of collections of persistent objects, we introduced a CollectionLoader that is used by the TrackingCollection when it has to access all of its elements. It is still possible however to use the TrackingCollection without a loader, and it will simply start empty and be considered loaded. Sherpa Solutions is offering the Apache Software Foundation the attached source code, to be distributed by the projet under the Apache License terms. -- 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: Code offer: TrackingCollection
Nicolas Marchildon a écrit : Sometimes you need to keep track of what was added and what was removed from a collection, and that is what we created TrackingCollection for. As requested, I booked a Jira ticket: http://issues.apache.org/jira/browse/COLLECTIONS-248 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-3) [configuration] Drop 1st class dependency on commons-logging
[ https://issues.apache.org/jira/browse/CONFIGURATION-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489130 ] Emmanuel Bourg commented on CONFIGURATION-3: I'd like to reopen this request, but schedule it for the next major release (2.0). Reducing the dependencies is desirable to simplify the usage of the library, commons logging could be replaced by the java.util logging API when we give up the Java 1.3 requirement. [configuration] Drop 1st class dependency on commons-logging Key: CONFIGURATION-3 URL: https://issues.apache.org/jira/browse/CONFIGURATION-3 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.2 Environment: Operating System: All Platform: Other Reporter: Joerg Schaible Priority: Minor 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] Reopened: (CONFIGURATION-3) [configuration] Drop 1st class dependency on commons-logging
[ https://issues.apache.org/jira/browse/CONFIGURATION-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Bourg reopened CONFIGURATION-3: [configuration] Drop 1st class dependency on commons-logging Key: CONFIGURATION-3 URL: https://issues.apache.org/jira/browse/CONFIGURATION-3 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.2 Environment: Operating System: All Platform: Other Reporter: Joerg Schaible Priority: Minor 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] Updated: (CONFIGURATION-3) Drop 1st class dependency on commons-logging
[ https://issues.apache.org/jira/browse/CONFIGURATION-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Bourg updated CONFIGURATION-3: --- Fix Version/s: 2.0 Issue Type: Improvement (was: Bug) Environment: (was: Operating System: All Platform: Other) Summary: Drop 1st class dependency on commons-logging (was: [configuration] Drop 1st class dependency on commons-logging) 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]
Re: [http-client] Does HttpClient support the HttpOnly cookie attribute?
On Sun, 2007-04-15 at 09:48 -0400, Tom Muldoon wrote: It appears that the HttpOnly cookie attribute is not recognized by the CookieSpec class (in both HttpClient 3.0 and 3.1rc). i.e. the following message is logged ... CookieSpec - Unrecognized cookie attribute: name=HttpOnly, value=null This appears to be a bit of a show stopper, as the server redirects the subsequent request back to the Login page after a seemingly successful login. In looking at the cookie that is included in the subsequent request, the HttpOnly attribute is missing altogether. So, does HttpClient support HttpOnly cookie attribute??? Tom, I am not aware of HttpOnly attribute mentioned anywhere in RFC2109 or RFC2965. HttpClient does not support cookie attributes that are not defined in the HTTP state management specification. Hope this helps Oleg Thanks in advance, Tom PS. Pardon me if this is a double-posting. I did post this a few days ago on the commons-user list but later realized that it was probably something that should have been posted to commons-dev. Is commons-user a subset of commons-dev? - 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]
[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 149 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: 28 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-16042007.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-16042007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-16042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-16042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-16042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-16042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-16042007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-16042007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-16042007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-16042007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-16042007.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
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 149 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: 28 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-16042007.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-16042007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-16042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-16042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-16042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-16042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-16042007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-16042007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-16042007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-16042007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-16042007.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
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 149 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-16042007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-16042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-16042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/beanshell/target/commons-jelly-tags-beanshell-16042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-16042007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-16042007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-16042007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-16042007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-16042007.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-16042007.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 149 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-16042007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-16042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-16042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/beanshell/target/commons-jelly-tags-beanshell-16042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-16042007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-16042007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-16042007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-16042007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-16042007.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-16042007.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: svn commit: r529210 - in /jakarta/commons/proper/configuration/trunk/src: java/org/apache/commons/configuration/DatabaseConfiguration.java test/org/apache/commons/configuration/TestDatabaseConfigu
I fear, making getConnection() package private is a binary incompatible
change. So please revert this change.
+1 for the enhanced documentation!
Oliver
[EMAIL PROTECTED] wrote:
Author: ebourg
Date: Mon Apr 16 04:54:11 2007
New Revision: 529210
URL: http://svn.apache.org/viewvc?view=revrev=529210
Log:
Improved the javadoc for DatabaseConfiguration
Made getConnection() package private since it's only used for testing
Modified:
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/DatabaseConfiguration.java
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestDatabaseConfiguration.java
Modified:
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/DatabaseConfiguration.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/DatabaseConfiguration.java?view=diffrev=529210r1=529209r2=529210
==
---
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/DatabaseConfiguration.java
(original)
+++
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/DatabaseConfiguration.java
Mon Apr 16 04:54:11 2007
@@ -33,11 +33,51 @@
import org.apache.commons.logging.LogFactory;
/**
- * Configuration stored in a database.
+ * Configuration stored in a database. The properties are retrieved from a
+ * table containing at least one column for the keys, and one column for the
+ * values. It's possible to store several configurations in the same table by
+ * adding a column containing the name of the configuration. The name of the
+ * table and the columns is specified in the constructor.
+ *
+ * h4Example 1 - One configuration per table/h4
+ *
+ * pre
+ * CREATE TABLE myconfig (
+ * `key` VARCHAR NOT NULL PRIMARY KEY,
+ * `value` VARCHAR
+ * );
+ *
+ * INSERT INTO myconfig (key, value) VALUES ('foo', 'bar');
+ *
+ *
+ * Configuration config = new DatabaseConfiguration(datasource, myconfig, key,
value);
+ * String value = config.getString(foo);
+ * /pre
+ *
+ * h4Example 2 - Multiple configurations per table/h4
+ *
+ * pre
+ * CREATE TABLE myconfigs (
+ * `name` VARCHAR NOT NULL,
+ * `key` VARCHAR NOT NULL,
+ * `value` VARCHAR,
+ * CONSTRAINT sys_pk_myconfigs PRIMARY KEY (`name`, `key`)
+ * );
+ *
+ * INSERT INTO myconfigs (name, key, value) VALUES ('config1', 'key1',
'value1');
+ * INSERT INTO myconfigs (name, key, value) VALUES ('config2', 'key2',
'value2');
+ *
+ *
+ * Configuration config1 = new DatabaseConfiguration(datasource, myconfigs, name, key,
value, config1);
+ * String value1 = conf.getString(key1);
+ *
+ * Configuration config2 = new DatabaseConfiguration(datasource, myconfigs, name, key,
value, config2);
+ * String value2 = conf.getString(key2);
+ * /pre
*
* @since 1.0
*
- * @author Emmanuel Bourg
+ * @author a href=mailto:[EMAIL PROTECTED]Emmanuel Bourg/a
* @version $Revision$, $Date$
*/
public class DatabaseConfiguration extends AbstractConfiguration
@@ -521,7 +561,7 @@
* @throws SQLException if an error occurs
* @since 1.4
*/
-protected Connection getConnection() throws SQLException
+Connection getConnection() throws SQLException
{
return getDatasource().getConnection();
}
Modified:
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestDatabaseConfiguration.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestDatabaseConfiguration.java?view=diffrev=529210r1=529209r2=529210
==
---
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestDatabaseConfiguration.java
(original)
+++
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestDatabaseConfiguration.java
Mon Apr 16 04:54:11 2007
@@ -133,8 +133,7 @@
*/
private PotentialErrorDatabaseConfiguration setUpConfig()
{
-return new PotentialErrorDatabaseConfiguration(datasource, TABLE,
-COL_KEY, COL_VALUE);
+return new PotentialErrorDatabaseConfiguration(datasource, TABLE,
COL_KEY, COL_VALUE);
}
/**
@@ -145,8 +144,7 @@
*/
private DatabaseConfiguration setUpMultiConfig()
{
-return new DatabaseConfiguration(datasource, TABLE_MULTI, COL_NAME,
-COL_KEY, COL_VALUE, CONFIG_NAME);
+return new DatabaseConfiguration(datasource, TABLE_MULTI, COL_NAME,
COL_KEY, COL_VALUE, CONFIG_NAME);
}
/**
@@ -157,8 +155,7 @@
private void setUpErrorListener(PotentialErrorDatabaseConfiguration config)
{
// remove log listener to avoid exception longs
-
Re: svn commit: r529210 - in /jakarta/commons/proper/configuration/trunk/src: java/org/apache/commons/configuration/DatabaseConfiguration.java test/org/apache/commons/configuration/TestDatabaseConfigu
Oliver Heger a écrit : I fear, making getConnection() package private is a binary incompatible change. So please revert this change. This change is not binary compatible indeed, but the method was protected, just introduced in configuration 1.4, and unlikely to be used by anyone (getDatasource().getConnection() is preferable to get a connection). I wish I could have seen this before the release, I'd like to keep the API as clean as possible and prevent unnecessary classes and methods in the javadocs, otherwise it's confusing for the users. +1 for the enhanced documentation! I'm still catching up on the unread mails of the dev list, someone complained about the lack of documentation for DatabaseConfiguration so I wrote the javadoc. An entry in the userguide would be nice too. Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r529210 - in /jakarta/commons/proper/configuration/trunk/src: java/org/apache/commons/configuration/DatabaseConfiguration.java test/org/apache/commons/configuration/TestDatabaseConfigu
Emmanuel Bourg wrote: Oliver Heger a écrit : I fear, making getConnection() package private is a binary incompatible change. So please revert this change. This change is not binary compatible indeed, but the method was protected, just introduced in configuration 1.4, and unlikely to be used by anyone (getDatasource().getConnection() is preferable to get a connection). I wish I could have seen this before the release, I'd like to keep the API as clean as possible and prevent unnecessary classes and methods in the javadocs, otherwise it's confusing for the users. Sorry, but our rules for releases are quite clear: no binary incompatible changes in a minor release. We can hide or remove this method in the 2.0 release, but not in a 1.x release. BTW it might be useful for a sub class to have an opportunity to hook into the mechanism of obtaining a connection. Oliver +1 for the enhanced documentation! I'm still catching up on the unread mails of the dev list, someone complained about the lack of documentation for DatabaseConfiguration so I wrote the javadoc. An entry in the userguide would be nice too. Emmanuel Bourg - 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: svn commit: r529210 - in /jakarta/commons/proper/configuration/trunk/src: java/org/apache/commons/configuration/DatabaseConfiguration.java test/org/apache/commons/configuration/TestDatabaseConfigu
Oliver Heger a écrit : Sorry, but our rules for releases are quite clear: no binary incompatible changes in a minor release. We can hide or remove this method in the 2.0 release, but not in a 1.x release. BTW it might be useful for a sub class to have an opportunity to hook into the mechanism of obtaining a connection. It's still possible to hook the connection used by the configuration by providing a custom Datasource, actually that's the purpose of a Datasource. I'll revert the change but mark the method as deprecated. Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JXPATH-80) boolean conversion of javabean getter values returning NULL fails
boolean conversion of javabean getter values returning NULL fails - Key: JXPATH-80 URL: https://issues.apache.org/jira/browse/JXPATH-80 Project: Commons JXPath Issue Type: Bug Affects Versions: 1.2 Final Environment: java.runtime.name=Java(TM) SE Runtime Environment java.runtime.version=1.6.0-b105 java.specification.name=Java Platform API Specification java.specification.vendor=Sun Microsystems Inc. java.vm.info=mixed mode java.vm.name=Java HotSpot(TM) Client VM Reporter: Nico Max Priority: Minor According to the JXPath User Guide a Javabean Getter returning NULL, regadless of the type, will be converted bo Boolean FALSE. But trying to build a boolean expression from this fails as the attached testcase shows. -- 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: (JXPATH-80) boolean conversion of javabean getter values returning NULL fails
[ https://issues.apache.org/jira/browse/JXPATH-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nico Max updated JXPATH-80: --- Attachment: test.java The testcase. boolean conversion of javabean getter values returning NULL fails - Key: JXPATH-80 URL: https://issues.apache.org/jira/browse/JXPATH-80 Project: Commons JXPath Issue Type: Bug Affects Versions: 1.2 Final Environment: java.runtime.name=Java(TM) SE Runtime Environment java.runtime.version=1.6.0-b105 java.specification.name=Java Platform API Specification java.specification.vendor=Sun Microsystems Inc. java.vm.info=mixed mode java.vm.name=Java HotSpot(TM) Client VM Reporter: Nico Max Priority: Minor Attachments: test.java According to the JXPath User Guide a Javabean Getter returning NULL, regadless of the type, will be converted bo Boolean FALSE. But trying to build a boolean expression from this fails as the attached testcase shows. -- 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: (JXPATH-80) boolean conversion of javabean getter values returning NULL fails
[ https://issues.apache.org/jira/browse/JXPATH-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nico Max updated JXPATH-80: --- Description: According to the JXPath User Guide a Javabean Getter returning NULL, regadless of the type, will be converted bo Boolean FALSE. But trying to build a boolean expression from this fails as the attached testcase shows. It seems that the type the bean getter returns matters, as a NULL String for example works as expected. was:According to the JXPath User Guide a Javabean Getter returning NULL, regadless of the type, will be converted bo Boolean FALSE. But trying to build a boolean expression from this fails as the attached testcase shows. boolean conversion of javabean getter values returning NULL fails - Key: JXPATH-80 URL: https://issues.apache.org/jira/browse/JXPATH-80 Project: Commons JXPath Issue Type: Bug Affects Versions: 1.2 Final Environment: java.runtime.name=Java(TM) SE Runtime Environment java.runtime.version=1.6.0-b105 java.specification.name=Java Platform API Specification java.specification.vendor=Sun Microsystems Inc. java.vm.info=mixed mode java.vm.name=Java HotSpot(TM) Client VM Reporter: Nico Max Priority: Minor Attachments: test.java According to the JXPath User Guide a Javabean Getter returning NULL, regadless of the type, will be converted bo Boolean FALSE. But trying to build a boolean expression from this fails as the attached testcase shows. It seems that the type the bean getter returns matters, as a NULL String for example works as expected. -- 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: (LANG-328) LocaleUtils.toLocale() rejects strings with only language+variant
LocaleUtils.toLocale() rejects strings with only language+variant - Key: LANG-328 URL: https://issues.apache.org/jira/browse/LANG-328 Project: Commons Lang Issue Type: Bug Affects Versions: 2.3 Reporter: Emmanuel Bourg LocaleUtils.toLocale() throws an exception on strings containing a language and a variant but no country code. For example : fr__POSIX This string can be produced with the JDK by instanciating a Locale with an empty string for the country : new Locale(fr, , POSIX).toString(). According to the javadoc for the Locale class a variant is allowed with just a language code or just a country code. Commons Configuration handles this case in its PropertyConverter.toLocale() method. I'd like to replace our implementation by the one provided by LocaleUtils, but our tests fail due to this case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (CONFIGURATION-265) XMLConfiguration with setAutoSave(true) doesn't save if SubnodeConfiguration is changed
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] Updated: (IO-117) EndianUtils.readSwappedUnsignedInteger() may return a negative number
[ https://issues.apache.org/jira/browse/IO-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiroshi Ikeda updated IO-117: - Attachment: EndianUtilsTest.java Here simple test case. EndianUtils.readSwappedUnsignedInteger() may return a negative number - Key: IO-117 URL: https://issues.apache.org/jira/browse/IO-117 Project: Commons IO Issue Type: Bug Affects Versions: 1.3.1 Reporter: Hiroshi Ikeda Attachments: EndianUtilsTest.java Methods about reading unsigned-integer in class EndianUtils may return a negative number, due to casting int to long. Calculations with operator etc. are under integer in these methods so its results are integer, then implicit casting the results to long keeps its positive/negative sign. -- 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: [lang] StringUtils startsWith / endsWith methods
Stephen Kestle had this view of case insensitivity: http://issues.apache.org/jira/browse/LANG-316 Given that I've a strong interest in multiple locales etc, I definitely see Stephen's point, but your example shows a good reason why the low ASCII chars do scale - domain names (at least until it all gets complicated at some unknown point in the future). Make them @since 3.0 (given that's what it is in JIRA). We can change that later if need be. Hen On 4/15/07, Niall Pemberton [EMAIL PROTECTED] wrote: I posted a patch for StringUtils to add a number of new methods to the following Jira ticket: http://issues.apache.org/jira/browse/LANG-326 Any objections to me committing this? Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-316) Enable CaseInsensitivity in EqualsBuilder and HashCodeBuilder
[ https://issues.apache.org/jira/browse/LANG-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489289 ] Henri Yandell commented on LANG-316: Agreed on the booleans - change the method name; ie) appendIgnoreCase(String, String). Unsure on Collators atm. The majority will just want ignoreCase, and I don't have the real world i18n experience to know whether collators are any good. If Sun reimplemented equalsIgnoreCase as a secondary strength default locale collator, would people be happy or would they complain? When we say ignore case, do we mean secondary/tertiary, or is it a different semantic to the collating? ie) Do I have to know the Locale first to know whether I want to choose secondary or tertiary (or identical)? Enable CaseInsensitivity in EqualsBuilder and HashCodeBuilder - Key: LANG-316 URL: https://issues.apache.org/jira/browse/LANG-316 Project: Commons Lang Issue Type: New Feature Affects Versions: 2.3 Environment: Any Reporter: Nelson Carpentier Priority: Minor Fix For: 3.0 Attachments: lang_20070206.diff Sometimes I want a String property containing ThisString to be seen as equal to THISstring. EqualsBuilder (and HashCodeBuilder) should be enhanced to optionally handle this requirement. -- 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: [lang] StringUtils startsWith / endsWith methods
Yeah - ascii still does scale in some cases. However, I imagine String.equalsIgnoreCase() is an exercise in legacy code conversion as well as speed. By all means, add ignoreCase for the shops that don't need/know better, but just make sure that Collator/Comparator use is an option, and is encouraged in the javadoc. I'm not sure how to raise a ticket for this, as it probably spans quite a few classes... Henri Yandell wrote: Stephen Kestle had this view of case insensitivity: http://issues.apache.org/jira/browse/LANG-316 Given that I've a strong interest in multiple locales etc, I definitely see Stephen's point, but your example shows a good reason why the low ASCII chars do scale - domain names (at least until it all gets complicated at some unknown point in the future). Make them @since 3.0 (given that's what it is in JIRA). We can change that later if need be. Hen On 4/15/07, Niall Pemberton [EMAIL PROTECTED] wrote: I posted a patch for StringUtils to add a number of new methods to the following Jira ticket: http://issues.apache.org/jira/browse/LANG-326 Any objections to me committing this? Niall - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (FILEUPLOAD-132) How do we retrieve the HTTP Headers in the request?
[ https://issues.apache.org/jira/browse/FILEUPLOAD-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489297 ] Lewis Choo Man commented on FILEUPLOAD-132: --- Thanks the the tip! I needed the former and retrieving the request headers from the HttpServletRequest object works! How do we retrieve the HTTP Headers in the request? --- Key: FILEUPLOAD-132 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-132 Project: Commons FileUpload Issue Type: Wish Affects Versions: 1.2 Environment: Open Suse 10.1 Reporter: Lewis Choo Man I would like to retrieve the HTTP request headers from the org.apache.commons.fileupload.FileUpload class, while still being able to save any file that is embedded in the HTTP body. Is there a public method to do so? -- 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: [cli-avalon] svn commit: r529044 - /jakarta/commons/proper/cli/branches/avalon-implementation/pom.xml
On 4/15/07, sebb [EMAIL PROTECTED] wrote:
On 15/04/07, Rahul Akolkar [EMAIL PROTECTED] wrote:
On 4/15/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: sebb
Date: Sun Apr 15 11:33:27 2007
New Revision: 529044
URL: http://svn.apache.org/viewvc?view=revrev=529044
Log:
Create minimal POM
Added:
jakarta/commons/proper/cli/branches/avalon-implementation/pom.xml
(with props)
[...]
Since this a new component, we should preferably discuss its creation
(then have a vote if needed etc.).
Not sure I follow that - all I've done is create a Pom so it can be
built independently - the code has been in SVN for some while now,
waiting for someone to do a release (please!)
snip/
If we look at what defines a component in the maven sense, we are
talking about the {groupId,artifactId} tuple, which is new in the POM
you added (my comment was under the artifactId line, I should have
spelt that out instead). In terms of development in Commons, I think
of branches as potentially different lines of development of the same
component, rather than potentially different components.
For [cli], we've ended up with a divergent set of codebases and
releasing each is probably not making it better. Its confusing,
suboptimal, and hopefully, avoidable. If enough of us want to see more
than one cli-ish component released out of Commons, then IMO it would
be nice to (not in any temporal order):
* Treat this as component creation (rather than just another [cli]
release), and acceptance into Commons Proper is usually via a vote
* Have a [cli-avalon] site
* Have all cli-ish components' sites point to each other, explain why
there are more than one, why users should prefer one over the other
etc.
-Rahul
Sebb
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (SCXML-44) Interface consistency: State.getIsFinal and State.setIsFinal
[ https://issues.apache.org/jira/browse/SCXML-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rahul Akolkar updated SCXML-44: --- Fix Version/s: 0.7 Lets aim to initiate a deprecate, replace and remove cycle starting v0.7. Interface consistency: State.getIsFinal and State.setIsFinal Key: SCXML-44 URL: https://issues.apache.org/jira/browse/SCXML-44 Project: Commons SCXML Issue Type: Improvement Affects Versions: 0.6 Reporter: Jörg Weinmann Priority: Trivial Fix For: 0.7 Getter and setter method for boolean isFinal is inconsistent to similiar getter and setter methods in the class. I would have expected: State.isFinal() and State.setFinal(). Compare to isDone(), isSimple(), isDone(), setDone(). -- 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]
