[jira] Created: (BEANUTILS-275) BeanUtils.setProperty: crashes when setting a java.util.Date simple property with a java.sql.Timestamp value

2007-04-25 Thread adelino (JIRA)
BeanUtils.setProperty: crashes when setting a java.util.Date simple property 
with a java.sql.Timestamp value


 Key: BEANUTILS-275
 URL: https://issues.apache.org/jira/browse/BEANUTILS-275
 Project: Commons BeanUtils
  Issue Type: Bug
  Components: Bean / Property Utils
Affects Versions: 1.7.0
 Environment: Test done on JVM 1.4.2 running on Windows 2000
Reporter: adelino
Priority: Blocker


BeanUtils.setProperty method converts a value of type java.sql.Timestamp to 
java.lang.String no matter the type of the property at the receiving end:

Timestamp selectedDate = new Timestamp( System.currentTimeMillis() );
// Class of target object has a getter and setter for property selectedDate of 
type java.util.Date 
BeanUtils.setProperty(target, selectedDate, selectedDate);
// THIS THROWS AN EXCEPTION  java.lang.IllegalArgumentException - argument type 
mismatch

Looking into the source code of the setProperty method I suspect that the 
following piece of code needs to be changed:
} else if (getConvertUtils().lookup(value.getClass()) != null) {
newValue = getConvertUtils().convert(value.toString(), type);
} else {

Indeed getConvertUtils().lookup(value.getClass())  returns a non null result 
since there is a converter registered for java.sql.Timestamp . The problem is 
that the newValue gets assigned with a String (because of value.toString()) 
whereas, at the beginning, we had an object assignable to java.util.Date 
without any conversion.

I have also checked the HEAD version of BeanUtils in SVN and this faulty piece 
of code is still there.

Please could fix this bug... Many thanks.

-- 
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-253) FileConfiguration getFile(), getFileName(), getBasePath() are not always consistent

2007-04-25 Thread Thomas Wabner (JIRA)

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

Thomas Wabner commented on CONFIGURATION-253:
-

I think that for my case the javadoc is not very helpful. If I create a new 
Configuration, there cannot be a source - or in this case the source is null. 

If a load method doesn't change the source, what means in this case load?

If I load any data into a configuration, I change the source of the 
configuration. The source in the configuration object should always point to 
the latest source object from outside.

I think we have to clearify what we mean with load.

Olivers quick fix means that the load method works as I aspected - it changes 
the source in the configuration to the last source for the configuration.

This should always only available for a file based configuration. In the case 
of the database configuration the bahavior should be differnet
(I don't have yet take a look into the database stuff).

So I vote to change the current behavior.

 FileConfiguration getFile(), getFileName(), getBasePath() are not always 
 consistent
 ---

 Key: CONFIGURATION-253
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-253
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.3
Reporter: Thomas Wabner
 Fix For: 1.5


 Taken from the maillinglist:
  I have a properties configuration which is loaded without a problem.
  Later in my application I will access the file which is aligned to 
  this configuration.
  
   
  
  final IFileConfiguration _productConf = 
  _conf.getProductConfigurations().get(_productId);
  
  log.debug(product conf file  + _productConf.getFile());
  
  log.debug(product conf filename  + _productConf.getFileName());
  
  log.debug(product conf base path  + _productConf.getBasePath());
  
   
  
  The methods _productConf.getFile() and _productConf.getFileName() 
  returning null but the getBasePath() returns a path which is correct 
  (like file:/C:/Projects/workspace/myProject/project.properties). Seems 
  for me like a bug because the PropertiesConfiguration is loaded 
  correct and works.
  
   
  
  By side: I have also set a file reloading strategy for this 
  configuration.
  
   
  
  Any ideas what's happen in this case or where I can find the problem? 
  It would be nicer to get the File() instead the BasePath which has to 
  be converted into a URL before I can access the whole properties file.
  
   
  
  Thanks in advance,
  
   
  
  - Thomas Wabner
  
  
 Thomas,
 you are right, the conversions between a base path, a file name, and a File 
 are not always consistent. How did you load the configuration (this 
 determines, which internal fields are set)?
 I would recommend to work with URLs, i.e. the method getURL(). A file-based 
 configuration's URL is always defined.
 If you like, you can open a Jira ticket for this problem.
 Thanks.
 Oliver
 The file is loaded in this way:
 _productConf = new ProductConfiguration();
 _productConf.load(FileTools.getPathForList(_propductPathList).getPath());
 means the load method gets an String and not an File.

-- 
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-253) FileConfiguration getFile(), getFileName(), getBasePath() are not always consistent

2007-04-25 Thread Emmanuel Bourg (JIRA)

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

Emmanuel Bourg commented on CONFIGURATION-253:
--

If the URL and the basepath are set on calling load(), then this is a bug since 
the source should not change.

If we have to change the current behavior, I prefer that load() changes the 
source only if no source is already set.

 FileConfiguration getFile(), getFileName(), getBasePath() are not always 
 consistent
 ---

 Key: CONFIGURATION-253
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-253
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.3
Reporter: Thomas Wabner
 Fix For: 1.5


 Taken from the maillinglist:
  I have a properties configuration which is loaded without a problem.
  Later in my application I will access the file which is aligned to 
  this configuration.
  
   
  
  final IFileConfiguration _productConf = 
  _conf.getProductConfigurations().get(_productId);
  
  log.debug(product conf file  + _productConf.getFile());
  
  log.debug(product conf filename  + _productConf.getFileName());
  
  log.debug(product conf base path  + _productConf.getBasePath());
  
   
  
  The methods _productConf.getFile() and _productConf.getFileName() 
  returning null but the getBasePath() returns a path which is correct 
  (like file:/C:/Projects/workspace/myProject/project.properties). Seems 
  for me like a bug because the PropertiesConfiguration is loaded 
  correct and works.
  
   
  
  By side: I have also set a file reloading strategy for this 
  configuration.
  
   
  
  Any ideas what's happen in this case or where I can find the problem? 
  It would be nicer to get the File() instead the BasePath which has to 
  be converted into a URL before I can access the whole properties file.
  
   
  
  Thanks in advance,
  
   
  
  - Thomas Wabner
  
  
 Thomas,
 you are right, the conversions between a base path, a file name, and a File 
 are not always consistent. How did you load the configuration (this 
 determines, which internal fields are set)?
 I would recommend to work with URLs, i.e. the method getURL(). A file-based 
 configuration's URL is always defined.
 If you like, you can open a Jira ticket for this problem.
 Thanks.
 Oliver
 The file is loaded in this way:
 _productConf = new ProductConfiguration();
 _productConf.load(FileTools.getPathForList(_propductPathList).getPath());
 means the load method gets an String and not an File.

-- 
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-224) BaseConfiguration.getProperty() returns reference to intenal store collection object instead of a clone

2007-04-25 Thread Emmanuel Bourg (JIRA)

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

Emmanuel Bourg commented on CONFIGURATION-224:
--

There is another alternative to this issue : getProperty() could return a 
decorator for Collection properties, the decorator would intercept the 
modifications to the collection and generate a configuration event.

That may be interesting for the getList() methods, I think it's important that 
getProperty() returns the stored object without modification.

 BaseConfiguration.getProperty() returns reference to intenal store collection 
 object instead of a clone
 ---

 Key: CONFIGURATION-224
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-224
 Project: Commons Configuration
  Issue Type: Bug
 Environment: 1.3RC2
Reporter: Gabriele Garuglieri
Priority: Minor
 Fix For: 1.3

 Attachments: list.patch


 When the property object is a List or an Array, 
 BaseConfiguration.getProperty() returns a reference to the object contained 
 in the store.
 This means that changing that object, changes the content of the properties 
 store without an explicit setProperty() or addProperty(). 
 Also any change to the object in the store will change the object that the 
 code has reference to, but the user is not aware that the property has 
 changed unless he has added a ConfigurationListener.
 Attached a patch to make the object returned by 
 BaseConfiguration.getProperty() a clone of store content, to avoid side 
 effects when changing Collection properties.

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

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

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



svn commit: r532326 - /jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestINIConfiguration.java

2007-04-25 Thread ebourg
Author: ebourg
Date: Wed Apr 25 04:48:00 2007
New Revision: 532326

URL: http://svn.apache.org/viewvc?view=revrev=532326
Log:
Fixed the failing test case for INIConfiguration on non Windows systems

Modified:

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

Modified: 
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestINIConfiguration.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestINIConfiguration.java?view=diffrev=532326r1=532325r2=532326
==
--- 
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestINIConfiguration.java
 (original)
+++ 
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestINIConfiguration.java
 Wed Apr 25 04:48:00 2007
@@ -30,33 +30,34 @@
 /**
  * Test class for INIConfiguration.
  *
- * @author trevor.miller
- * @version $Id: TestHierarchicalConfiguration.java 439648 2006-09-02 20:42:10Z
- * oheger $
+ * @author Trevor Miller
+ * @version $Id$
  */
 public class TestINIConfiguration extends TestCase
 {
-   /** Constant for the content of an ini file. */
+private static String LINE_SEPARATOR = 
System.getProperty(line.separator);
+
+/** Constant for the content of an ini file. */
private static final String INI_DATA =
-[section1]\r\n
-+ var1 = foo\r\n
-+ var2 = 451\r\n
-+ \r\n
-+ [section2]\r\n
-+ var1 = 123.45\r\n
-+ var2 = bar\r\n
-+ \r\n
-+ [section3]\r\n
-+ var1 = true\r\n
-+ \r\n;
+[section1] + LINE_SEPARATOR
++ var1 = foo + LINE_SEPARATOR
++ var2 = 451 + LINE_SEPARATOR
+ + LINE_SEPARATOR
++ [section2] + LINE_SEPARATOR
++ var1 = 123.45 + LINE_SEPARATOR
++ var2 = bar + LINE_SEPARATOR
+ + LINE_SEPARATOR
++ [section3] + LINE_SEPARATOR
++ var1 = true + LINE_SEPARATOR
+ + LINE_SEPARATOR;
 
private static final String INI_DATA2 =
-[section4]\r\n
-+ var1 = \quoted value\\r\n
-+ var2 = \quoted value\\nwith \\\quotes\r\n
-+ var3 = 123 ; comment\r\n
-+ var4 = \1;2;3\ ; comment\r\n
-+ var5 = '\\'quoted\\' \value\' ; comment\r\n;
+[section4] + LINE_SEPARATOR
++ var1 = \quoted value\ + LINE_SEPARATOR
++ var2 = \quoted value\\nwith \\\quotes + LINE_SEPARATOR
++ var3 = 123 ; comment + LINE_SEPARATOR
++ var4 = \1;2;3\ ; comment + LINE_SEPARATOR
++ var5 = '\\'quoted\\' \value\' ; comment;
 
 /**
  * Test of save method, of class [EMAIL PROTECTED] INIConfiguration}.
@@ -71,7 +72,8 @@
instance.addProperty(section2.var2, bar);
instance.addProperty(section3.var1, true);
instance.save(writer);
-   assertEquals(Wrong content of ini file, INI_DATA, 
writer.toString());
+
+assertEquals(Wrong content of ini file, INI_DATA, writer.toString());
}
 
/**



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



svn commit: r532336 - in /jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration: ./ event/ interpol/ plist/

2007-04-25 Thread ebourg
Author: ebourg
Date: Wed Apr 25 05:23:01 2007
New Revision: 532336

URL: http://svn.apache.org/viewvc?view=revrev=532336
Log:
Fixed several checkstyle warnings

Modified:

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

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

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

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

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

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

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

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

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

Modified: 
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/ConfigurationBuilder.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/ConfigurationBuilder.java?view=diffrev=532336r1=532335r2=532336
==
--- 
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/ConfigurationBuilder.java
 (original)
+++ 
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/ConfigurationBuilder.java
 Wed Apr 25 05:23:01 2007
@@ -14,6 +14,7 @@
  * See the License for the specific language governing permissions and
  * limitations under the License.
  */
+
 package org.apache.commons.configuration;
 
 /**
@@ -28,9 +29,7 @@
  * configuration constructed by this builder.
  * /p
  *
- * @author a
- * 
href=http://jakarta.apache.org/commons/configuration/team-list.html;Commons
- * Configuration team/a
+ * @author a 
href=http://jakarta.apache.org/commons/configuration/team-list.html;Commons 
Configuration team/a
  * @version $Id$
  */
 public interface ConfigurationBuilder

Modified: 
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/DataConfiguration.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/DataConfiguration.java?view=diffrev=532336r1=532335r2=532336
==
--- 
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/DataConfiguration.java
 (original)
+++ 
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/DataConfiguration.java
 Wed Apr 25 05:23:01 2007
@@ -223,7 +223,7 @@
 {
 if (Date.class.equals(cls) || Calendar.class.equals(cls))
 {
-return PropertyConverter.to(cls, interpolate(value), new 
String[] { getDefaultDateFormat() });
+return PropertyConverter.to(cls, interpolate(value), new 
String[] {getDefaultDateFormat()});
 }
 else
 {
@@ -289,7 +289,7 @@
 Object[] params = null;
 if (cls.equals(Date.class) || cls.equals(Calendar.class))
 {
-params = new Object[] { getDefaultDateFormat() };
+params = new Object[] {getDefaultDateFormat()};
 }
 
 try
@@ -300,7 +300,8 @@
 Class arrayType = valueClass.getComponentType();
 int length = Array.getLength(value);
 
-if (arrayType.equals(cls) || (arrayType.isPrimitive()  
cls.equals(ClassUtils.primitiveToWrapper(arrayType
+if (arrayType.equals(cls)
+|| (arrayType.isPrimitive()  
cls.equals(ClassUtils.primitiveToWrapper(arrayType
 {
 // the value is an array of the specified type, or an 
array
 // of the primitive type derived from the specified 
type
@@ -381,7 +382,8 @@
 // check the type of the default value
 if (defaultValue != null  (!defaultValue.getClass().isArray() || 
!cls.isAssignableFrom(defaultValue.getClass().getComponentType(
 {
-throw new IllegalArgumentException(The type of the default value 
( + defaultValue.getClass() + ) is not an array of the specified class ( + 
cls + ));
+throw new IllegalArgumentException(The type of the default value 
( + defaultValue.getClass() + )
++  is not 

Re: [sandbox] releasing parent sandbox pom

2007-04-25 Thread Carlos Sanchez

the source plugin 2.0.3 was just released, can we go ahead?

On 3/17/07, Niall Pemberton [EMAIL PROTECTED] wrote:

On 3/17/07, Carlos Sanchez [EMAIL PROTECTED] wrote:
 can the parent commons-sandbox be released so all sandbox components
 can be built by themselves?
 it just needs to have the parent version updated to 2

 or even better if commons parent is also released to take advantage of
 latest changes before releasing sandbox parent.

I was hoping the maven source plugin was going to get a release - so
that we could remove the antrun workaround for the source plugin bug -
then release a new commons parent. Unfortunately that seems to be
stalled on the maven list.

Niall

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





--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride

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



[beansutils] v1.7.1

2007-04-25 Thread maestro

Hi,

I have tried to locate some information on how to obtain the latest source
for v1.7.1 and build it.
I found information on how to build it... but nothing on how to get the
source. :(

Can anyone help me?
- maestro


[jira] Commented: (CONFIGURATION-253) FileConfiguration getFile(), getFileName(), getBasePath() are not always consistent

2007-04-25 Thread Oliver Heger (JIRA)

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

Oliver Heger commented on CONFIGURATION-253:


The behavior since (I think) the 1.2 release is that a load() call sets the 
sourceURL if none has been set so far. This is required for supporting features 
like auto save and reloading strategies for configurations created this way 
(there is no hint in the docs that a source must be set explicitly for using 
these features, so I assume this is alright). What my fix does is to always 
keep the getFile() method in sync with the sourceURL; so if a sourceURL exists, 
getFile() will now return a corresponding File object.

Note that the URL is only modified on an initial load() call, i.e. if already a 
source was set, it won't be changed by a following load() call. This is 
intended. It allows for instance the easy creation of combined configurations: 
you can call load() as often as you like on a file-based configuration; the 
properties of the single sources will be accumulated. Then you can save the 
accumulated properties to the original source.

 FileConfiguration getFile(), getFileName(), getBasePath() are not always 
 consistent
 ---

 Key: CONFIGURATION-253
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-253
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.3
Reporter: Thomas Wabner
 Fix For: 1.5


 Taken from the maillinglist:
  I have a properties configuration which is loaded without a problem.
  Later in my application I will access the file which is aligned to 
  this configuration.
  
   
  
  final IFileConfiguration _productConf = 
  _conf.getProductConfigurations().get(_productId);
  
  log.debug(product conf file  + _productConf.getFile());
  
  log.debug(product conf filename  + _productConf.getFileName());
  
  log.debug(product conf base path  + _productConf.getBasePath());
  
   
  
  The methods _productConf.getFile() and _productConf.getFileName() 
  returning null but the getBasePath() returns a path which is correct 
  (like file:/C:/Projects/workspace/myProject/project.properties). Seems 
  for me like a bug because the PropertiesConfiguration is loaded 
  correct and works.
  
   
  
  By side: I have also set a file reloading strategy for this 
  configuration.
  
   
  
  Any ideas what's happen in this case or where I can find the problem? 
  It would be nicer to get the File() instead the BasePath which has to 
  be converted into a URL before I can access the whole properties file.
  
   
  
  Thanks in advance,
  
   
  
  - Thomas Wabner
  
  
 Thomas,
 you are right, the conversions between a base path, a file name, and a File 
 are not always consistent. How did you load the configuration (this 
 determines, which internal fields are set)?
 I would recommend to work with URLs, i.e. the method getURL(). A file-based 
 configuration's URL is always defined.
 If you like, you can open a Jira ticket for this problem.
 Thanks.
 Oliver
 The file is loaded in this way:
 _productConf = new ProductConfiguration();
 _productConf.load(FileTools.getPathForList(_propductPathList).getPath());
 means the load method gets an String and not an File.

-- 
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: [beansutils] v1.7.1

2007-04-25 Thread Rahul Akolkar

On 4/25/07, maestro [EMAIL PROTECTED] wrote:

Hi,

I have tried to locate some information on how to obtain the latest source
for v1.7.1 and build it.
I found information on how to build it... but nothing on how to get the
source. :(

Can anyone help me?

snip/

svn co http://svn.apache.org/repos/asf/jakarta/commons/proper/beanutils/trunk

(you'll need a SVN client)

It appears there is no plan for a v1.7.1 any time soon.

-Rahul



- maestro



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



svn commit: r532471 - in /jakarta/commons/proper/configuration/trunk: src/java/org/apache/commons/configuration/AbstractFileConfiguration.java src/test/org/apache/commons/configuration/TestFileConfigu

2007-04-25 Thread oheger
Author: oheger
Date: Wed Apr 25 13:32:44 2007
New Revision: 532471

URL: http://svn.apache.org/viewvc?view=revrev=532471
Log:
CONFIGURATION-253: Keep result of FileConfiguration.getFile() in sync with 
getURL()

Modified:

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

jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestFileConfiguration.java
jakarta/commons/proper/configuration/trunk/xdocs/changes.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=532471r1=532470r2=532471
==
--- 
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
 Wed Apr 25 13:32:44 2007
@@ -617,7 +617,7 @@
  */
 public File getFile()
 {
-if (getFileName() == null)
+if (getFileName() == null  sourceURL == null)
 {
 return null;
 }

Modified: 
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestFileConfiguration.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestFileConfiguration.java?view=diffrev=532471r1=532470r2=532471
==
--- 
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestFileConfiguration.java
 (original)
+++ 
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestFileConfiguration.java
 Wed Apr 25 13:32:44 2007
@@ -39,8 +39,19 @@
  */
 public class TestFileConfiguration extends TestCase
 {
+/** Constant for the output directory.*/
 private static final File TARGET_DIR = new File(target);
 
+/** Constant for the directory with the test configuration files.*/
+private static final File TEST_DIR = new File(conf);
+
+/** Constant for the name of a test file.*/
+private static final String TEST_FILENAME = test.properties;
+
+/** Constant for a test file.*/
+private static final File TEST_FILE = new File(TEST_DIR, TEST_FILENAME);
+
+/** Constant for the name of a resource to be resolved.*/
 private static final String RESOURCE_NAME = 
config/deep/deeptest.properties;
 
 public void testSetURL() throws Exception
@@ -72,23 +83,23 @@
 {
 PropertiesConfiguration config = new PropertiesConfiguration();
 
-File directory = new File(conf);
-File file = new File(directory, test.properties);
+File directory = TEST_DIR;
+File file = TEST_FILE;
 config.setFile(file);
 assertEquals(directory.getAbsolutePath(), config.getBasePath());
-assertEquals(test.properties, config.getFileName());
+assertEquals(TEST_FILENAME, config.getFileName());
 assertEquals(file.getAbsolutePath(), config.getPath());
 
-config.setPath(conf + File.separator + test.properties);
-assertEquals(test.properties, config.getFileName());
+config.setPath(conf + File.separator + TEST_FILENAME);
+assertEquals(TEST_FILENAME, config.getFileName());
 assertEquals(directory.getAbsolutePath(), config.getBasePath());
 assertEquals(file.getAbsolutePath(), config.getPath());
 assertEquals(file.toURL(), config.getURL());
 
 config.setBasePath(null);
-config.setFileName(test.properties);
+config.setFileName(TEST_FILENAME);
 assertNull(config.getBasePath());
-assertEquals(test.properties, config.getFileName());
+assertEquals(TEST_FILENAME, config.getFileName());
 }
 
 public void testCreateFile1() throws Exception
@@ -289,7 +300,7 @@
  */
 public void testReloadingWithAutoSave() throws Exception
 {
-File configFile = new File(TARGET_DIR, test.properties);
+File configFile = new File(TARGET_DIR, TEST_FILENAME);
 PrintWriter out = null;
 
 try
@@ -379,7 +390,7 @@
 {
 FileConfiguration config = new PropertiesConfiguration();
 assertNull(config.getFile());
-File file = new File(conf/test.properties).getAbsoluteFile();
+File file = TEST_FILE.getAbsoluteFile();
 config.setFile(file);
 assertEquals(file, config.getFile());
 config.load();
@@ -387,13 +398,43 @@
 }
 
 /**
+ * Tests whether getFile() returns a valid file after a configuration has
+ * been loaded.
+ */
+public void testGetFileAfterLoad() 

[jira] Commented: (CONFIGURATION-253) FileConfiguration getFile(), getFileName(), getBasePath() are not always consistent

2007-04-25 Thread Oliver Heger (JIRA)

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

Oliver Heger commented on CONFIGURATION-253:


I applied the fix as described in my last comment. Thomas, can you please check 
if this works for you?
Thanks.

 FileConfiguration getFile(), getFileName(), getBasePath() are not always 
 consistent
 ---

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


 Taken from the maillinglist:
  I have a properties configuration which is loaded without a problem.
  Later in my application I will access the file which is aligned to 
  this configuration.
  
   
  
  final IFileConfiguration _productConf = 
  _conf.getProductConfigurations().get(_productId);
  
  log.debug(product conf file  + _productConf.getFile());
  
  log.debug(product conf filename  + _productConf.getFileName());
  
  log.debug(product conf base path  + _productConf.getBasePath());
  
   
  
  The methods _productConf.getFile() and _productConf.getFileName() 
  returning null but the getBasePath() returns a path which is correct 
  (like file:/C:/Projects/workspace/myProject/project.properties). Seems 
  for me like a bug because the PropertiesConfiguration is loaded 
  correct and works.
  
   
  
  By side: I have also set a file reloading strategy for this 
  configuration.
  
   
  
  Any ideas what's happen in this case or where I can find the problem? 
  It would be nicer to get the File() instead the BasePath which has to 
  be converted into a URL before I can access the whole properties file.
  
   
  
  Thanks in advance,
  
   
  
  - Thomas Wabner
  
  
 Thomas,
 you are right, the conversions between a base path, a file name, and a File 
 are not always consistent. How did you load the configuration (this 
 determines, which internal fields are set)?
 I would recommend to work with URLs, i.e. the method getURL(). A file-based 
 configuration's URL is always defined.
 If you like, you can open a Jira ticket for this problem.
 Thanks.
 Oliver
 The file is loaded in this way:
 _productConf = new ProductConfiguration();
 _productConf.load(FileTools.getPathForList(_propductPathList).getPath());
 means the load method gets an String and not an File.

-- 
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: r532478 - in /jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io: ModelUpdater.java SCXMLParser.java SCXMLSerializer.java

2007-04-25 Thread rahul
Author: rahul
Date: Wed Apr 25 13:50:29 2007
New Revision: 532478

URL: http://svn.apache.org/viewvc?view=revrev=532478
Log:
Feb '07 WD conformance changes for the IO package:
 - Update parser to support final, changed usage of parallel
 - Make static nested classes private
 - Add a Commons SCXML namespace to support implementation specific actions
 - Eliminate use of deprecated APIs
 

Modified:

jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/ModelUpdater.java

jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/SCXMLParser.java

jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/SCXMLSerializer.java

Modified: 
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/ModelUpdater.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/ModelUpdater.java?view=diffrev=532478r1=532477r2=532478
==
--- 
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/ModelUpdater.java
 (original)
+++ 
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/ModelUpdater.java
 Wed Apr 25 13:50:29 2007
@@ -61,21 +61,24 @@
String initialstate = scxml.getInitialstate();
//we have to use getTargets() here since the initialState can be
//an indirect descendant
-   // Concern marked by one of the code reviewers: better type check,
-   //now ClassCastException happens for Parallel
-   // Response: initial should be a State, for Parallel, it is implicit
-   State initialState = (State) scxml.getTargets().get(initialstate);
-   if (initialState == null) {
+   TransitionTarget initialTarget = (TransitionTarget) scxml.getTargets().
+   get(initialstate);
+   if (initialTarget == null) {
// Where do we, where do we go?
logAndThrowModelError(ERR_SCXML_NO_INIT, new Object[] {
initialstate });
}
-   scxml.setInitialState(initialState);
+   scxml.setInitialTarget(initialTarget);
Map targets = scxml.getTargets();
-   Map states = scxml.getStates();
-   Iterator i = states.keySet().iterator();
+   Map children = scxml.getChildren();
+   Iterator i = children.keySet().iterator();
while (i.hasNext()) {
-   updateState((State) states.get(i.next()), targets);
+   TransitionTarget tt = (TransitionTarget) children.get(i.next());
+   if (tt instanceof State) {
+   updateState((State) tt, targets);
+   } else {
+   updateParallel((Parallel) tt, targets); 
+   }
}
}
 
@@ -170,7 +173,7 @@
 Transition trn = (Transition) t.get(i);
 updateTransition(trn, targets);
 }
-Parallel p = s.getParallel();
+Parallel p = s.getParallel(); //TODO: Remove in v1.0
 Invoke inv = s.getInvoke();
 if ((inv != null  p != null)
 || (inv != null  !c.isEmpty())
@@ -216,7 +219,7 @@
   */
 private static void updateParallel(final Parallel p, final Map targets)
 throws ModelException {
-Iterator i = p.getStates().iterator();
+Iterator i = p.getChildren().iterator();
 while (i.hasNext()) {
 updateState((State) i.next(), targets);
 }
@@ -322,7 +325,7 @@
 return false; // One per region
 }
 }
-if (regions.size() != p.getStates().size()) {
+if (regions.size() != p.getChildren().size()) {
 return false; // Must represent all regions
 }
 return true;

Modified: 
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/SCXMLParser.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/SCXMLParser.java?view=diffrev=532478r1=532477r2=532478
==
--- 
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/SCXMLParser.java
 (original)
+++ 
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/SCXMLParser.java
 Wed Apr 25 13:50:29 2007
@@ -34,7 +34,6 @@
 import org.apache.commons.digester.SetNextRule;
 import org.apache.commons.digester.SetPropertiesRule;
 import org.apache.commons.logging.LogFactory;
-
 import org.apache.commons.scxml.PathResolver;
 import org.apache.commons.scxml.SCXMLHelper;
 import org.apache.commons.scxml.env.URLResolver;
@@ -49,6 +48,7 @@
 import org.apache.commons.scxml.model.Executable;
 import org.apache.commons.scxml.model.Exit;
 import org.apache.commons.scxml.model.ExternalContent;
+import org.apache.commons.scxml.model.Final;
 import org.apache.commons.scxml.model.Finalize;
 import org.apache.commons.scxml.model.History;
 import 

svn commit: r532480 - in /jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/semantics: SCXMLSemanticsImpl.java TransitionTargetComparator.java

2007-04-25 Thread rahul
Author: rahul
Date: Wed Apr 25 13:52:18 2007
New Revision: 532480

URL: http://svn.apache.org/viewvc?view=revrev=532480
Log:
Feb '07 WD related minor tweaks for the semantics package, mostly:
 - Eliminate use of deprecated APIs
 - Better naming as a consequence of above

 

Modified:

jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/semantics/SCXMLSemanticsImpl.java

jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/semantics/TransitionTargetComparator.java

Modified: 
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/semantics/SCXMLSemanticsImpl.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/semantics/SCXMLSemanticsImpl.java?view=diffrev=532480r1=532479r2=532480
==
--- 
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/semantics/SCXMLSemanticsImpl.java
 (original)
+++ 
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/semantics/SCXMLSemanticsImpl.java
 Wed Apr 25 13:52:18 2007
@@ -109,8 +109,8 @@
 /**
  * @param input
  *SCXML state machine [in]
- * @param states
- *a set of States to populate [out]
+ * @param targets
+ *a set of initial targets to populate [out]
  * @param entryList
  *a list of States and Parallels to enter [out]
  * @param errRep
@@ -120,19 +120,19 @@
  * @throws ModelException
  * in case there is a fatal SCXML object model problem.
  */
-public void determineInitialStates(final SCXML input, final Set states,
+public void determineInitialStates(final SCXML input, final Set targets,
 final List entryList, final ErrorReporter errRep,
 final SCInstance scInstance)
 throws ModelException {
-State tmp = input.getInitialState();
+TransitionTarget tmp = input.getInitialTarget();
 if (tmp == null) {
 errRep.onError(ErrorConstants.NO_INITIAL,
 SCXML initialstate is missing!, input);
 } else {
-states.add(tmp);
-determineTargetStates(states, errRep, scInstance);
+targets.add(tmp);
+determineTargetStates(targets, errRep, scInstance);
 //set of ALL entered states (even if initialState is a jump-over)
-Set onEntry = SCXMLHelper.getAncestorClosure(states, null);
+Set onEntry = SCXMLHelper.getAncestorClosure(targets, null);
 // sort onEntry according state hierarchy
 Object[] oen = onEntry.toArray();
 onEntry.clear();
@@ -261,8 +261,8 @@
 //let's check its siblings too
 Parallel p = (Parallel) parent.getParent();
 int finCount = 0;
-int pCount = p.getStates().size();
-for (Iterator regions = p.getStates().iterator();
+int pCount = p.getChildren().size();
+for (Iterator regions = p.getChildren().iterator();
 regions.hasNext();) {
 State reg = (State) regions.next();
 if (reg.isDone()) {
@@ -505,7 +505,7 @@
 for (Iterator k = regs.iterator(); k.hasNext();) {
 State region = (State) k.next();
 regions.addAll(((Parallel) region.getParent()).
-getStates());
+getChildren());
 }
 }
 }
@@ -548,7 +548,7 @@
 // NOTE: Digester has to verify this precondition!
 if (st.isSimple()) {
 states.add(st); //leaf
-} else if (st.isOrthogonal()) {
+} else if (st.isOrthogonal()) { //TODO: Remove else if in v1.0
 wrkSet.addLast(st.getParallel()); //parallel
 } else {
 // composite state
@@ -558,7 +558,7 @@
 }
 } else if (tt instanceof Parallel) {
 Parallel prl = (Parallel) tt;
-for (Iterator i = prl.getStates().iterator(); i.hasNext();) {
+for (Iterator i = prl.getChildren().iterator(); i.hasNext();) {
 //fork
 wrkSet.addLast(i.next());
 }

Modified: 
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/semantics/TransitionTargetComparator.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/semantics/TransitionTargetComparator.java?view=diffrev=532480r1=532479r2=532480
==
--- 

svn commit: r532482 - /jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/SCXMLHelper.java

2007-04-25 Thread rahul
Author: rahul
Date: Wed Apr 25 13:53:01 2007
New Revision: 532482

URL: http://svn.apache.org/viewvc?view=revrev=532482
Log:
Remove deprecated API usage.

Modified:

jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/SCXMLHelper.java

Modified: 
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/SCXMLHelper.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/SCXMLHelper.java?view=diffrev=532482r1=532481r2=532482
==
--- 
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/SCXMLHelper.java
 (original)
+++ 
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/SCXMLHelper.java
 Wed Apr 25 13:53:01 2007
@@ -152,7 +152,7 @@
 Set count = (Set) entry.getValue();
 if (tt instanceof Parallel) {
 Parallel p = (Parallel) tt;
-if (count.size()  p.getStates().size()) {
+if (count.size()  p.getChildren().size()) {
 errRep.onError(ErrorConstants.ILLEGAL_CONFIG,
 Not all AND states active for parallel 
 + p.getId(), entry);
@@ -249,7 +249,7 @@
 Parallel par = ((Parallel) ((State) regions.next()).
 getParent());
 //let's find affected states in sibling regions
-for (Iterator siblings = par.getStates().iterator();
+for (Iterator siblings = par.getChildren().iterator();
 siblings.hasNext();) {
 State s = (State) siblings.next();
 for (Iterator act = currentStates.iterator();



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



svn commit: r532485 - /jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/test/StandaloneUtils.java

2007-04-25 Thread rahul
Author: rahul
Date: Wed Apr 25 14:00:45 2007
New Revision: 532485

URL: http://svn.apache.org/viewvc?view=revrev=532485
Log:
Switch the test package to use new parser.

Modified:

jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/test/StandaloneUtils.java

Modified: 
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/test/StandaloneUtils.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/test/StandaloneUtils.java?view=diffrev=532485r1=532484r2=532485
==
--- 
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/test/StandaloneUtils.java
 (original)
+++ 
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/test/StandaloneUtils.java
 Wed Apr 25 14:00:45 2007
@@ -32,7 +32,7 @@
 import org.apache.commons.scxml.env.SimpleScheduler;
 import org.apache.commons.scxml.env.Tracer;
 import org.apache.commons.scxml.invoke.SimpleSCXMLInvoker;
-import org.apache.commons.scxml.io.SCXMLDigester;
+import org.apache.commons.scxml.io.SCXMLParser;
 import org.apache.commons.scxml.io.SCXMLSerializer;
 import org.apache.commons.scxml.model.ModelException;
 import org.apache.commons.scxml.model.SCXML;
@@ -76,7 +76,7 @@
 String documentURI = getCanonicalURI(uri);
 Context rootCtx = evaluator.newContext(null);
 Tracer trc = new Tracer();
-SCXML doc = SCXMLDigester.digest(new URL(documentURI), trc);
+SCXML doc = SCXMLParser.parse(new URL(documentURI), trc);
 if (doc == null) {
 System.err.println(The SCXML document  + uri
 +  can not be parsed!);



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



svn commit: r532486 - in /jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml: ./ io/ semantics/

2007-04-25 Thread rahul
Author: rahul
Date: Wed Apr 25 14:06:11 2007
New Revision: 532486

URL: http://svn.apache.org/viewvc?view=revrev=532486
Log:
JUnit test cases update:
 - Remove deprecated API usage
 - Wire up the tests added in r522070 for the new parser

Modified:

jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/SCXMLExecutorTest.java

jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/SCXMLHelperTest.java

jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/io/IOTestSuite.java

jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/io/SCXMLDigesterTest.java

jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/io/SCXMLSerializerTest.java

jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/semantics/TransitionTargetComparatorTest.java

Modified: 
jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/SCXMLExecutorTest.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/SCXMLExecutorTest.java?view=diffrev=532486r1=532485r2=532486
==
--- 
jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/SCXMLExecutorTest.java
 (original)
+++ 
jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/SCXMLExecutorTest.java
 Wed Apr 25 14:06:11 2007
@@ -28,6 +28,7 @@
 
 import org.apache.commons.scxml.env.SimpleContext;
 import org.apache.commons.scxml.env.jsp.ELEvaluator;
+import org.apache.commons.scxml.model.SCXML;
 import org.apache.commons.scxml.model.State;
 import org.apache.commons.scxml.model.TransitionTarget;
 /**
@@ -50,8 +51,8 @@
 
 // Test data
 private URL microwave01jsp, microwave02jsp, microwave01jexl,
-microwave02jexl, transitions01, transitions02, transitions03,
-prefix01, send01, send02;
+microwave02jexl, microwave03jexl, microwave04jexl, transitions01,
+transitions02, transitions03, transitions04, prefix01, send01, send02;
 private SCXMLExecutor exec;
 
 /**
@@ -66,12 +67,18 @@
 getResource(org/apache/commons/scxml/env/jexl/microwave-01.xml);
 microwave02jexl = this.getClass().getClassLoader().
 getResource(org/apache/commons/scxml/env/jexl/microwave-02.xml);
+microwave03jexl = this.getClass().getClassLoader().
+getResource(org/apache/commons/scxml/env/jexl/microwave-03.xml);
+microwave04jexl = this.getClass().getClassLoader().
+getResource(org/apache/commons/scxml/env/jexl/microwave-04.xml);
 transitions01 = this.getClass().getClassLoader().
 getResource(org/apache/commons/scxml/transitions-01.xml);
 transitions02 = this.getClass().getClassLoader().
 getResource(org/apache/commons/scxml/transitions-02.xml);
 transitions03 = this.getClass().getClassLoader().
 getResource(org/apache/commons/scxml/transitions-03.xml);
+transitions04 = this.getClass().getClassLoader().
+getResource(org/apache/commons/scxml/transitions-04.xml);
 prefix01 = this.getClass().getClassLoader().
 getResource(org/apache/commons/scxml/prefix-01.xml);
 send01 = this.getClass().getClassLoader().
@@ -85,8 +92,8 @@
  */
 public void tearDown() {
 microwave01jsp = microwave02jsp = microwave01jexl = microwave02jexl =
-transitions01 = transitions02 = transitions03 = prefix01 =
-send01 = send02 = null;
+microwave04jexl = transitions01 = transitions02 = transitions03 =
+transitions04 = prefix01 = send01 = send02 = null;
 }
 
 /**
@@ -118,6 +125,24 @@
 checkMicrowave02Sample();
 }
 
+// Uses SCXMLParser (latest WD)
+public void testSCXMLExecutorMicrowave03JexlSample() {
+SCXML scxml = SCXMLTestHelper.parse(microwave03jexl);
+assertNotNull(scxml);
+exec = SCXMLTestHelper.getExecutor(scxml);
+assertNotNull(exec);
+checkMicrowave01Sample();
+}
+
+// Uses SCXMLParser (latest WD)
+public void testSCXMLExecutorMicrowave04JexlSample() {
+SCXML scxml = SCXMLTestHelper.parse(microwave04jexl);
+assertNotNull(scxml);
+exec = SCXMLTestHelper.getExecutor(scxml);
+assertNotNull(exec);
+checkMicrowave02Sample();
+}
+
 public void testSCXMLExecutorPrefix01Sample() {
 exec = SCXMLTestHelper.getExecutor(prefix01);
 assertNotNull(exec);
@@ -193,6 +218,36 @@
 fail(e.getMessage());
 }
 }
+
+// Uses SCXMLParser (latest WD)
+public void testSCXMLExecutorTransitions04Sample() {
+SCXML scxml = SCXMLTestHelper.parse(transitions04);
+assertNotNull(scxml);
+exec = SCXMLTestHelper.getExecutor(scxml);
+assertNotNull(exec);
+try {
+

svn commit: r532488 - /jakarta/commons/proper/scxml/trunk/xdocs/usecases/scxml-stopwatch/

2007-04-25 Thread rahul
Author: rahul
Date: Wed Apr 25 14:11:39 2007
New Revision: 532488

URL: http://svn.apache.org/viewvc?view=revrev=532488
Log:
svn:ignore

Modified:
jakarta/commons/proper/scxml/trunk/xdocs/usecases/scxml-stopwatch/   (props 
changed)

Propchange: jakarta/commons/proper/scxml/trunk/xdocs/usecases/scxml-stopwatch/
--
--- svn:ignore (added)
+++ svn:ignore Wed Apr 25 14:11:39 2007
@@ -0,0 +1 @@
+Thumbs.db



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



[jira] Commented: (CONFIGURATION-253) FileConfiguration getFile(), getFileName(), getBasePath() are not always consistent

2007-04-25 Thread Emmanuel Bourg (JIRA)

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

Emmanuel Bourg commented on CONFIGURATION-253:
--

That looks good, the structure of the chained else/if could even be simplified.

 FileConfiguration getFile(), getFileName(), getBasePath() are not always 
 consistent
 ---

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


 Taken from the maillinglist:
  I have a properties configuration which is loaded without a problem.
  Later in my application I will access the file which is aligned to 
  this configuration.
  
   
  
  final IFileConfiguration _productConf = 
  _conf.getProductConfigurations().get(_productId);
  
  log.debug(product conf file  + _productConf.getFile());
  
  log.debug(product conf filename  + _productConf.getFileName());
  
  log.debug(product conf base path  + _productConf.getBasePath());
  
   
  
  The methods _productConf.getFile() and _productConf.getFileName() 
  returning null but the getBasePath() returns a path which is correct 
  (like file:/C:/Projects/workspace/myProject/project.properties). Seems 
  for me like a bug because the PropertiesConfiguration is loaded 
  correct and works.
  
   
  
  By side: I have also set a file reloading strategy for this 
  configuration.
  
   
  
  Any ideas what's happen in this case or where I can find the problem? 
  It would be nicer to get the File() instead the BasePath which has to 
  be converted into a URL before I can access the whole properties file.
  
   
  
  Thanks in advance,
  
   
  
  - Thomas Wabner
  
  
 Thomas,
 you are right, the conversions between a base path, a file name, and a File 
 are not always consistent. How did you load the configuration (this 
 determines, which internal fields are set)?
 I would recommend to work with URLs, i.e. the method getURL(). A file-based 
 configuration's URL is always defined.
 If you like, you can open a Jira ticket for this problem.
 Thanks.
 Oliver
 The file is loaded in this way:
 _productConf = new ProductConfiguration();
 _productConf.load(FileTools.getPathForList(_propductPathList).getPath());
 means the load method gets an String and not an File.

-- 
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-159) Save the changes made to a CompositeConfiguration

2007-04-25 Thread Emmanuel Bourg (JIRA)

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

Emmanuel Bourg commented on CONFIGURATION-159:
--

I'm thinking about adding a flush() method to the Configuration interface 
similar to the flush() method in the Preferences API :

http://java.sun.com/javase/6/docs/api/java/util/prefs/Preferences.html#flush()

The concept of making the changes persistent is not specific to the file 
configurations, we need it here for CompositeConfiguration, and we'll need it 
for DatabaseConfiguration to implement the caching mechanism.




 Save the changes made to a CompositeConfiguration
 -

 Key: CONFIGURATION-159
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-159
 Project: Commons Configuration
  Issue Type: Improvement
Affects Versions: 1.0
 Environment: Operating System: All
 Platform: All
Reporter: Sagar Kar
Priority: Minor
 Fix For: 1.5


 Hi,
 I used a CompositeConfiguration object to load all my properties and xml 
 files.
 I expose these configuration properties in a JMX console.
 These properties coming from many different files can be modified at runtime 
 in
 memory. But I need to store these back to the original files from where they
 were picked, so that I dont loose them if the server is restarted.
 The problem that I faced is whenever a property is being modified, it gets 
 moved
 from the original configuration to a BaseConfiguration object.
 What I would like is the change being made to the original configuration 
 object
 as well.
 Thanks ,
 Sagar

-- 
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-262) Binary property list format

2007-04-25 Thread Emmanuel Bourg (JIRA)

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

Emmanuel Bourg updated CONFIGURATION-262:
-

Fix Version/s: (was: 1.5)
   1.6

 Binary property list format
 ---

 Key: CONFIGURATION-262
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-262
 Project: Commons Configuration
  Issue Type: New Feature
Reporter: Emmanuel Bourg
Priority: Minor
 Fix For: 1.6

 Attachments: CFBinaryPList.c


 With OS X 10.4 Apple introduced a variant of the plist format that is 
 compressed using a binary format. That would be nice to support this format 
 with a BinaryPropertyListConfiguration class.
 I haven't found the specification of this format. 
 The plutil tool can be used to convert between xml and binary plist files.

-- 
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-258) JSON configuration

2007-04-25 Thread Emmanuel Bourg (JIRA)

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

Emmanuel Bourg updated CONFIGURATION-258:
-

Fix Version/s: (was: 1.5)
   1.6
  Environment: (was:
« Hide
Operating System: All
Platform: All
)

 JSON configuration
 --

 Key: CONFIGURATION-258
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-258
 Project: Commons Configuration
  Issue Type: Improvement
Affects Versions: 1.3
Reporter: Antonio López-Cerón Vivo
Priority: Minor
 Fix For: 1.6


 JSON  is a lightweight data-interchange format
 {menu: {
   id: file,
   value: File,
   popup: {
 menuitem: [
   {value: New, onclick: CreateNewDoc()},
   {value: Open, onclick: OpenDoc()},
   {value: Close, onclick: CloseDoc()}
 ]
   }
 }}
 All references can be located at
 http://www.json.org/

-- 
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-180) Cache DatabaseConfiguration values for higher performance

2007-04-25 Thread Emmanuel Bourg (JIRA)

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

Emmanuel Bourg commented on CONFIGURATION-180:
--

I see several solutions to improve the performances by caching the properties. 
We may either :

1. load the entire configuration in memory. A flush() method would save the 
new/modified properties back to the database, a sync() method would reload the 
properties. That may be nice to reuse the reloading strategies but currently 
they are specific to the file configurations, that will require some 
refactoring.

2. keep in memory the properties read for a certain time. getProperty(foo) 
will hit the database only if foo was read more than 5 minutes ago for example. 
The delay would be adjustable. Setting a property would still hit the database 
directly.

3. same as 2, but the configuration is preloaded once.


The caching should be optional to preserve the current behavior if needed.

 Cache DatabaseConfiguration values for higher performance
 -

 Key: CONFIGURATION-180
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-180
 Project: Commons Configuration
  Issue Type: Improvement
Reporter: Stephen Cooper
 Assigned To: Emmanuel Bourg
Priority: Minor
 Fix For: 1.5

 Attachments: dbpreload.txt, Enhancement33553.checkstyle.patch, 
 Enhancement33553.patch


 The DatabaseConfiguration class queries each property as it gets the request 
 for each property.  This is 
 nice for ensuring that you're always up to date, but it doesn't give very 
 good performance in enterprise 
 applications, where the database may not be on the same subnet.
 What we need is the ability to hit the database once, get all the keys/values 
 and then serve up 
 getString etc. from that cache.
 I'll be opening a separate enhancement to have a generic Reloading Strategy 
 which could then be 
 applied to this caching DatabaseConfiguration approach.

-- 
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-126) [configuration] SubsetConfiguration.getList throws exception

2007-04-25 Thread Emmanuel Bourg (JIRA)

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

Emmanuel Bourg updated CONFIGURATION-126:
-

Fix Version/s: 1.0
  Environment: (was: Operating System: other
Platform: All)

 [configuration] SubsetConfiguration.getList throws exception
 

 Key: CONFIGURATION-126
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-126
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: Nightly Builds
Reporter: Joerg Schaible
Priority: Blocker
 Fix For: 1.0

 Attachments: get-list.diff


 SubsetConfiguration.getList is not usable anymore, method(s) throw always a
 ClassCastException claiming ArrayList is not a List!
 Will add patch for test 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] Updated: (CONFIGURATION-27) [configuration] subset method on xml configuration does not work as expected

2007-04-25 Thread Emmanuel Bourg (JIRA)

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

Emmanuel Bourg updated CONFIGURATION-27:


Fix Version/s: 1.2
  Description: (was:  )
  Environment: (was: Operating System: All
Platform: All)

 [configuration] subset method on xml configuration does not work as expected
 

 Key: CONFIGURATION-27
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-27
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.1
Reporter: Fabien Nisol
Priority: Blocker
 Fix For: 1.2




-- 
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-89) [configuration] Setting the reloading strategy to FileChangedReloadingStrategy erases entire configuration

2007-04-25 Thread Emmanuel Bourg (JIRA)

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

Emmanuel Bourg updated CONFIGURATION-89:


Fix Version/s: 1.2

 [configuration] Setting the reloading strategy to 
 FileChangedReloadingStrategy erases entire configuration
 --

 Key: CONFIGURATION-89
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-89
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.1
 Environment: Operating System: Windows XP
 Platform: PC
Reporter: Blaine R Southam
Priority: Critical
 Fix For: 1.2

 Attachments: AbstractFileConfiguration.diff, 
 TestFileConfiguration.diff


 When setting a PropertiesConfiguration reloading strategy to
 FileChangedReloadingStrategy - the entire configuration is erased.
 The problem is that when the FileChangedReloadingStrategy is set, the
 configuration file is erased and then reloaded and then written out.
 The file is erased in AbstractFileConfiguration.save(File) when a new
 FileOutputStream is created.  Then in the PropertiesConfiguration.save(Writer)
 the call to getKeys() causes a reaload() to occur (which the strategy says 
 needs
 to be reloaded because it has been modified).  But the saved config file is 
 now
 zeroed out by the new file stream, and it is read in as an empty config.
 Here is a testcase that exposed this defect:
 public void
 testPropertiesConfigurationWithFileChangedReloadingStrategyDefect() throws
 ConfigurationException, FileNotFoundException, IOException {
 FileWriter file = new FileWriter(testfile.properties);
 file.write(a=1);
 file.close();
 FileConfiguration config = new
 PropertiesConfiguration(testfile.properties);
 config.setAutoSave(true);
 config.setReloadingStrategy(new FileChangedReloadingStrategy());
 assertEquals(1, config.getString(a));
 config.setProperty(2, b);
 assertEquals(1, config.getString(a));
 }

-- 
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-23) [Configuration] Property throwExceptionOnMissing is not respected for subsets

2007-04-25 Thread Emmanuel Bourg (JIRA)

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

Emmanuel Bourg updated CONFIGURATION-23:


Fix Version/s: 1.0
  Environment: (was: Operating System: All
Platform: All)

 [Configuration] Property throwExceptionOnMissing is not respected for subsets
 -

 Key: CONFIGURATION-23
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-23
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: Nightly Builds
Reporter: Joerg Schaible
Priority: Critical
 Fix For: 1.0


 public void testNoSuchElementExceptionFoSubsets() {
 BaseConfiguration config = new BaseConfiguration();
 config.setThrowExceptionOnMissing(true);
 config.addProperty(subset.foo, bar);
 try {
 config.getString(subset.foobar);
 fail(NoSuchElementException expected);
 } catch(NoSuchElementException e) {
 // expected
 }
 try {
 config.subset(subset).getString(foobar);
 fail(NoSuchElementException expected);
 } catch(NoSuchElementException e) {
 // expected
 }
 }
 This behaviour is currently a showstopper, since I rely on the thrown 
 exception.
 Note: subset() returns a plain Configuration interface, that does not have the
 setThrowExceptionOnMissing setter.

-- 
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-6) [configuration] XMLConfiguration inconsistency towards empty values

2007-04-25 Thread Emmanuel Bourg (JIRA)

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

Emmanuel Bourg updated CONFIGURATION-6:
---

Fix Version/s: 1.2
  Environment: (was: Operating System: other
Platform: All)

 [configuration] XMLConfiguration inconsistency towards empty values
 ---

 Key: CONFIGURATION-6
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-6
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.1
Reporter: Etienne Lacazedieu
 Fix For: 1.2


 Empty values are not read correctly from XML files : when a XML file contains 
 an
 empty element, the corresponding keys are not present in the configuration, 
 but
 an empty string can be saved!
 Consider the following code : 
 XMLConfiguration config = new XMLConfiguration();
 config.setProperty(foo.bar, );
 config.save(config.xml);
 System.out.println(Config saved!);
 System.out.println(foo.bar in config1 = +config.getProperty(foo.bar));
 XMLConfiguration config2 = new XMLConfiguration(config.xml);
 System.out.println(foo.bar in config2= +config2.getProperty(foo.bar));
 The output is : 
 foo.bar in config1 = ''
 foo.bar in config2 = 'null'
 the file config.xml contains : 
 configuration
 foo
  bar/
 /foo
 /configuration
 this also does not allow to distinguish between an empty value and a missing 
 key.

-- 
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-2) [configuration] [1.2RC1] ConfigurationDynaBean may implement java.util.Map

2007-04-25 Thread Emmanuel Bourg (JIRA)

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

Emmanuel Bourg updated CONFIGURATION-2:
---

Fix Version/s: 1.2

 [configuration] [1.2RC1] ConfigurationDynaBean may implement java.util.Map
 --

 Key: CONFIGURATION-2
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-2
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: Nightly Builds
 Environment: Operating System: other
 Platform: Other
Reporter: nicolas de loof
 Fix For: 1.2


 ConfigurationDynaBean says 
 It also implements a Map interface so that it can be used in JSP 2.0 
 Expression
 Language expressions.
 Map interface is not implemented (in 1.2RC1) and ConfigurationDynaBean cannot 
 be
 used from EL :
 c:out value=${configuration['un.test']}/ :
 Unable to find a value for un.test in object of class
 org.apache.commons.configuration.beanutils.ConfigurationDynaBean using
 operator [] (null)
 Simply implementing Map.get(Object) may solve the problem.

-- 
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-33) [configuration] Clarify ReloadingStrategy interface usage

2007-04-25 Thread Emmanuel Bourg (JIRA)

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

Emmanuel Bourg updated CONFIGURATION-33:


Fix Version/s: 1.2
  Environment: (was: Operating System: other
Platform: Other)

 [configuration] Clarify ReloadingStrategy interface usage
 -

 Key: CONFIGURATION-33
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-33
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.1
Reporter: nicolas de loof
 Fix For: 1.2


 I had some trouble creating a ReloadingStrategy implementation (based on a JMX
 reload request) : 
 reloadingRequired() is called several times AFTER first returning 'true' and
 before reloadingPerformed() is called. In fact, reloading process requires
 access to getProperty() that itself (re)enters reload. If reloadingRequired()
 doens't return false at this time, a infinite recursice loop starts.
 Perhaps it is a reload() bug, that may use a boolean flag to mark
 processing-reload and avoid such infinite loop in the Thread runing he reload.

-- 
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-36) [configuration] HierarchicalConfiguration.getKeys(String) might return empty iterator

2007-04-25 Thread Emmanuel Bourg (JIRA)

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

Emmanuel Bourg updated CONFIGURATION-36:


Fix Version/s: 1.1

 [configuration] HierarchicalConfiguration.getKeys(String) might return empty 
 iterator
 -

 Key: CONFIGURATION-36
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-36
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.0
 Environment: Operating System: other
 Platform: Other
Reporter: Oliver Heger
 Fix For: 1.1

 Attachments: hierarchicalconfig.txt, HierarchicalConfiguration.txt, 
 testhierarchicalconfig.txt, TestHierarchicalConfiguration.txt, 
 TestSubsetConfiguration.txt


 If called with a prefix string that contains indices, the implementation of
 getKeys(String) inherited from AbstractConfiguration fails to find keys with 
 the
 passed in prefix. So the returned iterator is empty.
 This patch provides a specific implementation of this method for
 HierarchicalConfiguration that solves this problem.

-- 
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-35) [configuration] PropertiesConfiguration.load should default to encoding 8859_1

2007-04-25 Thread Emmanuel Bourg (JIRA)

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

Emmanuel Bourg updated CONFIGURATION-35:


Fix Version/s: 1.2

 [configuration] PropertiesConfiguration.load should default to encoding 
 8859_1
 

 Key: CONFIGURATION-35
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-35
 Project: Commons Configuration
  Issue Type: Bug
 Environment: Operating System: other
 Platform: Other
Reporter: Will Glass-Husain
 Fix For: 1.2


 Same issue as:
 http://issues.apache.org/bugzilla/show_bug.cgi?id=17616
 Copied from 17616
 The default load method for commons.collections.ExtendedProperties currently 
 loads properties using the default JVM encoding.  The default load() method 
 should use 8859_1 encoding.
 Rationale:
 1) consistency: java.util.Properties.load() method always uses 8859_1
 2) properties resources are always 8859_1, by convention.
 2) On edbcic machines, particularly IBM mainframes, the default encoding is 
 Cp1047 (ebcdic), but properties files are always ASCII (ISO8859-1)
 3) This bug causes many Apache tools, such as Velocity, which uses 
 commons.collections, to fail on non-ascii machines, since they distribute 
 properties resources which are (correctly) in 8859-1.

-- 
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-37) [configuration] DOMConfiguration can't replace DOM4JConfiguration

2007-04-25 Thread Emmanuel Bourg (JIRA)

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

Emmanuel Bourg updated CONFIGURATION-37:


Fix Version/s: 1.0

 [configuration] DOMConfiguration can't replace DOM4JConfiguration
 -

 Key: CONFIGURATION-37
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-37
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: Nightly Builds
 Environment: Operating System: All
 Platform: All
Reporter: Emmanuel Bourg
 Fix For: 1.0


 I tried to replace DOM4JConfiguration in the ConfigurationFactory with
 DOMConfiguration:
 @@ -281,7 +281,7 @@
  setupDigesterInstance(
  digester,
  matchString + dom4j,
 -new BasePathConfigurationFactory(DOM4JConfiguration.class),
 +new BasePathConfigurationFactory(DOMConfiguration.class),
  METH_LOAD,
  additional);
  setupDigesterInstance(
 But one test breaks in TestConfigurationFactory:
 Testcase:
 testAllConfiguration(org.apache.commons.configuration.TestConfigurationFactory):
   Caused
 an ERROR
 SAX Exception caught
 org.apache.commons.configuration.ConfigurationException: SAX Exception caught
   at
 org.apache.commons.configuration.ConfigurationFactory.getConfiguration(ConfigurationFactory.java:164)
   at
 org.apache.commons.configuration.TestConfigurationFactory.testAllConfiguration(TestConfigurationFactory.java:229)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 Caused by: org.apache.commons.configuration.ConfigurationException: Could not
 load from
 D:\dev\apache\jakarta-commons\configuration\file:\D:\dev\apache\jakarta-commons\configuration\conf\testDigesterConfiguration3.xml\test.xml
   at 
 org.apache.commons.digester.Digester.createSAXException(Digester.java:2540)
   at 
 org.apache.commons.digester.Digester.createSAXException(Digester.java:2566)
   at org.apache.commons.digester.Digester.endElement(Digester.java:1061)
   at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown 
 Source)
   at 
 org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown 
 Source)
   at
 org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown
 Source)
   at
 org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
 Source)
   at 
 org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
 Source)
   at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
   at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
   at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
   at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
   at org.apache.commons.digester.Digester.parse(Digester.java:1567)
   at
 org.apache.commons.configuration.ConfigurationFactory.getConfiguration(ConfigurationFactory.java:158)
   ... 15 more

-- 
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-38) [configuration][patch]Removed JDK 1.4 dependency

2007-04-25 Thread Emmanuel Bourg (JIRA)

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

Emmanuel Bourg updated CONFIGURATION-38:


Fix Version/s: 1.0

 [configuration][patch]Removed JDK 1.4 dependency
 

 Key: CONFIGURATION-38
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-38
 Project: Commons Configuration
  Issue Type: Bug
 Environment: Operating System: other
 Platform: Other
Reporter: Oliver Heger
 Fix For: 1.0

 Attachments: ConfigurationKey.txt


 In ConfigurationKey class there have been two references to the
 StringBuffer.indexOf() method, which is new in JDK 1.4. This patch removes 
 this
 dependency.

-- 
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-39) [configuration] FileChangedReloadingStrategy javadoc misleading

2007-04-25 Thread Emmanuel Bourg (JIRA)

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

Emmanuel Bourg updated CONFIGURATION-39:


Fix Version/s: 1.2

 [configuration] FileChangedReloadingStrategy javadoc misleading
 ---

 Key: CONFIGURATION-39
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-39
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.1
 Environment: Operating System: All
 Platform: All
Reporter: John Nikolai
Priority: Trivial
 Fix For: 1.2


 The current javadoc for 1.1 version of Configuration is as follows:
 -
 A reloading strategy that will reload the configuration every time its 
 underlying file is changed. The file 
 is not reloaded more than once every 5 seconds by default, this time can be 
 changed by setting the 
 refresh delay. This strategy only works with FileConfiguration instances.
 -
 I was under the false impression that a thread would be created which would 
 periodically wake up every 
 5 seconds and poll the property file to see if it has changed or not. If the 
 file has changed then it would 
 be reloaded. However this is not the case. After diving into the code, you 
 need to call one of the get*() 
 methods (i.e. getInt(), getLong(), etc...) before the file is checked.
 Finally, it would be nice to have some kind of callback mechanism to notify 
 listeners that implement a 
 well known interface defined in the configuration API that the file has 
 changed.
 Thanks for all your hard work!

-- 
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-41) [configuration] Output format of FileConfiguration classes

2007-04-25 Thread Emmanuel Bourg (JIRA)

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

Emmanuel Bourg updated CONFIGURATION-41:


Fix Version/s: 1.2

 [configuration] Output format of FileConfiguration classes
 --

 Key: CONFIGURATION-41
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-41
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.1
 Environment: Operating System: Windows 2000
 Platform: Other
Reporter: Kay Doebl
 Fix For: 1.2

 Attachments: properties_lineseparator.patch, XML_encoding.patch


 I am using Commons Configuration 1.1.
 Saving 'FielConfiguration's the configuration files will be overwritten every 
 time.
 Bad if you have formatted them with descriptions and comments ... but this is
 not so important.
 Not so good is, that in the class:
 PropertiesConfiguration:
 '\n' is used as line separator and not the 
 System.getProperty(line.separator).
 So, on Windows systems the configuration files are badly readable.
 XMLConfiguration:
 The encoding is not looped though to the encoding in the XML head declaration.
 Every time UTF-8 is set (?xml version=1.0 encoding=UTF-8?)
 I would prefer that my encoding (setEncoding()) is reflected in the XML 
 document.
 Is there a reason that it is implemented like you do?
 Attached are patches which would resolve the problems (if you want):
 PropertiesConfiguration.java:
 properties_lineseparator.patch
 136a137,138
  private static final String lineSeparator =
 System.getProperty(line.separator);
  
 344c346
  out.write(\n);
 ---
  out.write(lineSeparator);
 349c351
  out.write(\n);
 ---
  out.write(lineSeparator);
 486c488
  write('\n');
 ---
  write(lineSeparator);
 511c513
  write(#  + comment + \n);
 ---
  write(#  + comment + lineSeparator);
 XMLConfiguration.java:
 XML_encoding.patch
 446a447
  transformer.setOutputProperty(OutputKeys.ENCODING, 
  getEncoding());

-- 
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-45) [configuration] Fails silently if asked to save to an invalid filename

2007-04-25 Thread Emmanuel Bourg (JIRA)

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

Emmanuel Bourg updated CONFIGURATION-45:


Fix Version/s: 1.1

 [configuration] Fails silently if asked to save to an invalid filename
 --

 Key: CONFIGURATION-45
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-45
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.0
 Environment: Operating System: All
 Platform: All
Reporter: Iain Shepherd
 Fix For: 1.1


 Running code like this...
 FileConfiguration config = new PropertiesConfiguration();
 config.setFile(new File(/invalid/path/my.properties));
 config.save();
 ...doesn't throw any Exception. AbstractFileConfiguration.save(File) swallows 
 the FileNotFoundException, prints a stack trace, and completes normally, 
 without having saved the file.
 Cheers
 Iain Shepherd

-- 
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-46) [Configuration] Documentation Issue

2007-04-25 Thread Emmanuel Bourg (JIRA)

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

Emmanuel Bourg updated CONFIGURATION-46:


Fix Version/s: 1.0

 [Configuration] Documentation Issue
 ---

 Key: CONFIGURATION-46
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-46
 Project: Commons Configuration
  Issue Type: Bug
 Environment: Operating System: other
 Platform: Other
Reporter: Tim Reilly
 Fix For: 1.0

 Attachments: examples-patch.txt


 I think there's an error in the documentation for commons-configuration 
 examples page.
 If I use this example:
ConfigurationFactory factory = new ConfigurationFactory();
URL configURL = getClass().getResource(/config.xml);
factory.setConfigurationFileName(configURL.toString());
Configuration config = factory.getConfiguration();
 I get a NPE, but if I change to this:
   ConfigurationFactory factory = new ConfigurationFactory();
   URL configURL = getClass().getResource(/config.xml);
 - factory.setConfigurationFileName(configURL.toString());
 + factory.setConfigurationFileName(configURL.getFile());
   Configuration config = factory.getConfiguration();
 everthing is fine. Basically, the setConfigFileName in ConfigurationFactory 
 is 
 not expecting a URI its expecting a path i think?

-- 
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-49) [configuration] XMLConfiguration may lose attributes in its save() method

2007-04-25 Thread Emmanuel Bourg (JIRA)

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

Emmanuel Bourg updated CONFIGURATION-49:


Fix Version/s: 1.2

 [configuration] XMLConfiguration may lose attributes in its save() method
 -

 Key: CONFIGURATION-49
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-49
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.1
 Environment: Operating System: All
 Platform: All
Reporter: Oliver Heger
 Fix For: 1.2


 Under some circumstances (if a configuration is loaded, cleared and then
 reloaded), the save() method forgets to write attributes. Their values are 
 still
 contained in the configuration object itself, but they are not written to the
 output file.

-- 
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-50) [configuration] FileChangedReloadingStrategy fails to properly detect file change

2007-04-25 Thread Emmanuel Bourg (JIRA)

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

Emmanuel Bourg updated CONFIGURATION-50:


Fix Version/s: 1.2

 [configuration] FileChangedReloadingStrategy fails to properly detect file 
 change
 -

 Key: CONFIGURATION-50
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-50
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.1
 Environment: Operating System: Windows XP
 Platform: Other
Reporter: Eric Lee
 Fix For: 1.2

 Attachments: ConfigurationChangedReloadingStrategy.java, 
 ConfigurationUtils.java.patch, patch.diff, patch.diff


 Two code examples that fail to detect / load file changes:
 =Sample
 1:  If properties file location is determined by searching the classpath,
 changes are not detected.
 try {
 PropertiesConfiguration propConfig = new
 PropertiesConfiguration(commons.properties);
 FileChangedReloadingStrategy strategy = new FileChangedReloadingStrategy();
 strategy.setConfiguration(propConfig);
 strategy.setRefreshDelay(500);
 strategy.init();
 for (;;){
 String prop1 = propConfig.getString(prop1);
 System.out.println(Calendar.getInstance().getTime() +  :  +
 strategy.reloadingRequired() +  :  + prop1);
 Thread.sleep(1000);
 }
 } catch (Throwable t){
 t.printStackTrace();
 }
 =
 Sample 2:  If properties file location is specified, changes are not detected
 but not loaded.
 try {
 PropertiesConfiguration propConfig = new
 PropertiesConfiguration(d:/tmp/commons.properties);
 FileChangedReloadingStrategy strategy = new FileChangedReloadingStrategy();
 strategy.setConfiguration(propConfig);
 strategy.setRefreshDelay(500);
 strategy.init();
 for (;;){
 String prop1 = propConfig.getString(prop1);
 System.out.println(Calendar.getInstance().getTime() +  :  +
 strategy.reloadingRequired() +  :  + prop1);
 Thread.sleep(1000);
 }
 } catch (Throwable t){
 t.printStackTrace();
 }

-- 
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-54) [configuration] BaseConfiguration: containsKey ignores default properties

2007-04-25 Thread Emmanuel Bourg (JIRA)

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

Emmanuel Bourg updated CONFIGURATION-54:


Fix Version/s: 1.0

 [configuration] BaseConfiguration: containsKey ignores default properties
 -

 Key: CONFIGURATION-54
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-54
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: Nightly Builds
 Environment: Operating System: All
 Platform: All
Reporter: Christian Siefkes
 Fix For: 1.0


 The current (CVS Head) implementation of BaseConfiguration.containsKey does 
 not
 check whether a key is contained in the defaults Configuration (if exists).
 I think
 public boolean containsKey(String key)
 {
 return store.containsKey(key);
 }
 should be:
 public boolean containsKey(String key)
 {
 return store.containsKey(key)
|| ((defaults != null)  defaults.containsKey(key));
 }

-- 
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-56) [configuration] Property substitution doesn't work for subsets anymore

2007-04-25 Thread Emmanuel Bourg (JIRA)

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

Emmanuel Bourg updated CONFIGURATION-56:


Fix Version/s: 1.0

 [configuration] Property substitution doesn't work for subsets anymore
 --

 Key: CONFIGURATION-56
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-56
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: Nightly Builds
 Environment: Operating System: other
 Platform: All
Reporter: Joerg Schaible
 Fix For: 1.0

 Attachments: CompositeConfiguration.java.diff, 
 project.properties.diff, SubsetConfiguration.java.diff, 
 SubsetConfiguration.java.diff, TestCompositeConfiguration.java.diff


 The last refactoring of the subsets eliminated the previously working property
 substitution by chance.
 Patches follow.
 CAUTION: The patches revert a workaround for HierarchicalConfiguration, which
 makes 'illegal' internal assuptions about the implementation.

-- 
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-58) [configuration] Wrong primitive conversion in DataConfiguration

2007-04-25 Thread Emmanuel Bourg (JIRA)

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

Emmanuel Bourg updated CONFIGURATION-58:


Fix Version/s: 1.1

 [configuration] Wrong primitive conversion in DataConfiguration
 ---

 Key: CONFIGURATION-58
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-58
 Project: Commons Configuration
  Issue Type: Bug
 Environment: Operating System: All
 Platform: All
Reporter: Emmanuel Bourg
 Fix For: 1.1


 The values in getLongArray(), getFloatArray() and getDoubleArray() are not
 converted to the right type, they are all converted into integers.
 Index: DataConfiguration.java
 ===
 --- DataConfiguration.java(revision 153417)
 +++ DataConfiguration.java(working copy)
 @@ -825,7 +826,7 @@
  Iterator it = values.iterator();
  while (it.hasNext())
  {
 -array[i++] = PropertyConverter.toLong(it.next()).intValue();
 +array[i++] = PropertyConverter.toLong(it.next()).longValue();
  }
  }
  else
 @@ -834,7 +835,7 @@
  {
  // attempt to convert a single value
  array = new long[1];
 -array[0] = PropertyConverter.toLong(value).intValue();
 +array[0] = PropertyConverter.toLong(value).longValue();
  }
  catch (ConversionException e)
  {
 @@ -974,7 +975,7 @@
  Iterator it = values.iterator();
  while (it.hasNext())
  {
 -array[i++] = PropertyConverter.toFloat(it.next()).intValue();
 +array[i++] = 
 PropertyConverter.toFloat(it.next()).floatValue();
  }
  }
  else
 @@ -983,7 +984,7 @@
  {
  // attempt to convert a single value
  array = new float[1];
 -array[0] = PropertyConverter.toFloat(value).intValue();
 +array[0] = PropertyConverter.toFloat(value).floatValue();
  }
  catch (ConversionException e)
  {
 @@ -1124,7 +1125,7 @@
  Iterator it = values.iterator();
  while (it.hasNext())
  {
 -array[i++] = 
 PropertyConverter.toDouble(it.next()).intValue();
 +array[i++] = 
 PropertyConverter.toDouble(it.next()).doubleValue();
  }
  }
  else
 @@ -1133,7 +1134,7 @@
  {
  // attempt to convert a single value
  array = new double[1];
 -array[0] = PropertyConverter.toDouble(value).intValue();
 +array[0] = PropertyConverter.toDouble(value).doubleValue();
  }
  catch (ConversionException e)
  {

-- 
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-60) [configuration] XML How-to needs to be updated for RC-1

2007-04-25 Thread Emmanuel Bourg (JIRA)

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

Emmanuel Bourg updated CONFIGURATION-60:


Fix Version/s: 1.0

 [configuration] XML How-to needs to be updated for RC-1
 ---

 Key: CONFIGURATION-60
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-60
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: Nightly Builds
 Environment: Operating System: other
 Platform: Other
Reporter: woodman
 Fix For: 1.0

 Attachments: howto.txt


 jakarta-commons\configuration\xdocs\howto_xml.xml needs to be updated to 
 match 
 the deliverables in RC-1.   The exclusion of ConfigurationXMLDocument is the 
 main thing I noticed that needs to be addressed.

-- 
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-61) [configuration] JNDIConfiguration and union configuration

2007-04-25 Thread Emmanuel Bourg (JIRA)

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

Emmanuel Bourg updated CONFIGURATION-61:


Fix Version/s: 1.0

 [configuration] JNDIConfiguration and union configuration
 -

 Key: CONFIGURATION-61
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-61
 Project: Commons Configuration
  Issue Type: Bug
 Environment: Operating System: other
 Platform: Other
Reporter: Oliver Heger
 Fix For: 1.0

 Attachments: testconfigurationfactory.txt, 
 testDigesterConfiguration3.xml


 JNDIConfiguration seems not to work with ConfigurationFactory when used in the
 additional section. The union configuration feature of ConfigurationFactory 
 is
 implemented by calling getKeys() on a Configuration object, iterating through
 the keys, and calling getProperty() for each.
 JNDIConfiguration.getKeys() obviously always returns an empty iterator in my
 tests though the Configuration object is not empty (getString() returns values
 for some keys). I am not sure whether this is a bug in JNDIConfiguration or a
 shortcomming of the JNDI implementation used for testing.
 Another point is that JNDIConfiguration.getProperty() always throws a not
 supported error. This would also blow ConfigurationFactory if getKeys() 
 returned
 a valid iterator. I don't understand why this error is thrown. In my opinion
 this is a violation of the contract defined by the Configuration interface 
 (the
 same is true for some other methods).
 Attached is an extension to the unit test of ConfigurationFactory that
 demonstrates the problem.

-- 
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-62) [configuration] Using FileChangedReloadingStrategy for XMLConfiguration

2007-04-25 Thread Emmanuel Bourg (JIRA)

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

Emmanuel Bourg updated CONFIGURATION-62:


Fix Version/s: 1.2

 [configuration] Using FileChangedReloadingStrategy for XMLConfiguration
 ---

 Key: CONFIGURATION-62
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-62
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.1
 Environment: Operating System: Windows 2000
 Platform: Other
Reporter: Raman
 Fix For: 1.2


 We are trying to use FileChangedReloadingStrategy for XMLConfiguration, but 
 its 
 not working. 
 We are using CompositeConfiguration and we have properties files as well as 
 some xml files. 
 I set FileChangedReloadingStrategy for all the configuration which is sub  
 class of FileConfiguration. But reloading is only working for properties.
 Code:
 
 Configuration config = null;
 ConfigurationFactory factory = new ConfigurationFactory();
 String configFile=c:/config.xml;
 factory.setConfigurationFileName(configFile);
 config = factory.getConfiguration();
 CompositeConfiguration cc=((CompositeConfiguration)config);
 int noOfConfig=cc.getNumberOfConfigurations();
 for(int i=0;inoOfConfig;i++){
 System.out.println(cc.getConfiguration(i).getClass() + :  + 
 (cc.getConfiguration(i)  instanceof  FileConfiguration));
 if((cc.getConfiguration(i)  instanceof  FileConfiguration)){
 ((FileConfiguration)cc.getConfiguration(i)).setReloadingStrategy(new 
 FileChangedReloadingStrategy());
 }
 Is it possible to use FileChangedReloadingStrategy for xmlconfiguration.

-- 
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-63) [configuration] ConfigurationUtils.locate throws NullPointerException if the context ClassLoader is null

2007-04-25 Thread Emmanuel Bourg (JIRA)

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

Emmanuel Bourg updated CONFIGURATION-63:


Affects Version/s: (was: 1.2)
   1.3

 [configuration] ConfigurationUtils.locate throws NullPointerException if the 
 context ClassLoader is null
 

 Key: CONFIGURATION-63
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-63
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 1.3
 Environment: Operating System: Windows XP
 Platform: PC
Reporter: nomus

 Hello,
 When the locate method attempts to find resource location from the context 
 classpath 
 (lines 375-384 in ConfigurationUtils.java) it fails (on line 378) if the 
 context 
 ClassLoader cannot be retrieved for the current thread.
 I suppose this bug is quite difficult to reproduce. I came accross it when I 
 and a 
 colleague of mine were testing a Java API (kept in one jar) that is called 
 from C++ 
 application. In the static initializer of a Java class I used the next line 
 to load 
 settings:
 config = new 
 PropertiesConfiguration(ConfigurationUtils.locate(properties/routing.
 properties));
 It worked fine if the class was used from another Java class that was 
 normally loaded 
 by JVM (for example my tests passed). But when my Java classes were executed 
 by JVM 
 started from C++ application it resulted in the next exception:
 java.lang.NullPointerException
   at org.apache.commons.configuration.ConfigurationUtils.
 locate(ConfigurationUtils.java:378)
   at org.apache.commons.configuration.ConfigurationUtils.
 locate(ConfigurationUtils.java:255)
 ...
 It is obvious from the ConfigurationUtils code that loader variable got null 
 value 
 (line 377) for some reason so the next step threw the exception.
 I suppose this bug can be easily fixed (just to add an additional check if 
 loader is 
 not null).
 As a workaround I will try to call locate method with a given base parameter 
 (but it 
 needs to determine location of my jar so it is a kind of overheads though it 
 would 
 work I hope).
 Sorry for my English.
 Hope it is useful,
 Denis

-- 
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-64) [configuration] clearXmlProperty doesn't remove list properties completely

2007-04-25 Thread Emmanuel Bourg (JIRA)

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

Emmanuel Bourg updated CONFIGURATION-64:


Fix Version/s: 1.0

 [configuration] clearXmlProperty doesn't remove list properties completely
 --

 Key: CONFIGURATION-64
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-64
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: Nightly Builds
 Environment: Operating System: All
 Platform: All
Reporter: Emmanuel Bourg
 Fix For: 1.0

 Attachments: clear-property-2.txt, clear-property.txt, 
 clear-xml-property.diff


 clearXmlProperty in XMLConfiguration stops on the first element found and
 doesn't examine the whole tree, that means calling clearXmlProperty on a list
 property only remove the first element. For example, given the following
 configuration file:
 configuration
 keyvalue1/key
 keyvalue2/key
 /configuration
 calling conf.clearProperty(key) and saving the configuration will generate 
 the
 following file instead of an empty configuration:
 configuration
 keyvalue2/key
 /configuration

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



java.lang.OutOfMemoryError - IOUtils.copy - When file size larger than 7 MB

2007-04-25 Thread Bibs L
  Hi,
  I am stuck with a java.lang.OutOfMemoryError when I try to copy a file of 
about 7 MB from a window server. I am using the org.apache.commons.io.IOUtils, 
  IOUtils.copy(fileIn, response.getOutputStream()) with Survlet response to get 
the download diaglog to pop up.
   
  This is working fine when I run it locally - (download file larger than 7MB), 
but when I deploy the code to Shaed Environment- (download the SAME file larger 
than 7MB), it is throwing java.lang.OutOfMemoryError Exception. And evertime it 
throw the OutOfMemoryError, it creates a heapdumpdateTimestamp.phd file and a 
javacoredateTimeStamp File on the shared environemnt's profile location. 
   
  Does anyone know what I need to do to fix this issue? 
   
  The only thing I could think of is that the memory is low on the server, do 
we need to increase the JVM heap? What's the down side to that? 
  Is it something I am doing wring in my Code below? I could download file size 
less than 7MB.
   
  A few notes about our shared envirnment:
  - We are running WebSphere 6.0 on Window server
  - It is a Virtual Machine
  - 4 GBs on server, but is split to 4 server instance, so we have about 1 GB
  - The code below is executed on WebSphere, but the file that need to be 
downloaded is on a different window server - shared server - 
//serverName/somedir/file.doc 
   
  I would greatly appreciate any help you could offer 
THANKS!
   
  Here's my code:
   
  FileInputStream fileIn = null;
  File file = null;
  URL url = null;
  URLConnection urlConn = null;
  InputStream in = null;
  PrintWriter pw = null; 
  try{
  file = new File(\\serverPath\download\documents\test.doc); 
  
  if(file.exists() == true){ 
  LOG.debug(file exists...); 
  
  //generate URL for file 
  url = file.toURL(); 
  urlConn = url.openConnection(); 
  in = url.openStream();
  
  fileIn = new FileInputStream(file); 
  
  response.setContentType(urlConn.getContentType()); 
  response.setHeader(Content-Disposition,inline; filename=\ + 
file.getName() + \);
  
  LOG.debug(urlConn.getContentType() =  + urlConn.getContentType());
  
  long startTime = System.currentTimeMillis(); 
  
  IOUtils.copy(fileIn, response.getOutputStream());
  response.setStatus(response.SC_OK);
  response.flushBuffer(); 
  
  LOG.debug(Total Time Taken to download: +(System.currentTimeMillis() - 
startTime) +  ms); renderFileFlag = true; 
  
  }else{ 
  LOG.debug(file not found...); 
  } 
  } catch (FileNotFoundExceptione) { 
  LOG.error(FileNotFoundExceptione: download -  + e.getMessage(), e);
  
  } catch (IOExceptione) { 
  LOG.error(IOException: download -  + e.getMessage(), e); 
  
  } catch (Exception e) { 
  LOG.error(Exception : download -  + e.getMessage(), e);
  
  } finally { 
  if (facesContext != null) facesContext = null; 
  if (fileIn != null) fileIn.close(); 
  if (file != null) file = null; 
  if (url != null) url = null;
  if (urlConn != null) urlConn = null;
  if (in != null) in.close(); 
  if (pw != null) pw.close();
  } 
   

-
  Ahhh...imagining that irresistible new car smell?
Check out new cars at Yahoo! Autos. 

   
-
Ahhh...imagining that irresistible new car smell?
 Check outnew cars at Yahoo! Autos.

java.lang.OutOfMemoryError - IOUtils.copy - When file size larger than 7 MB

2007-04-25 Thread Bibs L
Hi,
I am stuck with a java.lang.OutOfMemoryError when I try to copy a file of about 
7 MB from a window server. I am using the org.apache.commons.io.IOUtils, 
IOUtils.copy(fileIn, response.getOutputStream()) with Survlet response to get 
the download diaglog to pop up.

This is working fine when I run it locally - (download file larger than 7MB), 
but when I deploy the code to Shaed Environment- (download the SAME file larger 
than 7MB), it is throwing java.lang.OutOfMemoryError Exception. And evertime it 
throw the OutOfMemoryError, it creates a heapdump.phd file and a javacore File 
on the shared environemnt's profile location. 

Does anyone know what I need to do to fix this issue? 

The only thing I could think of is that the memory is low on the server, do we 
need to increase the JVM heap? What's the down side to that? 
Is it something I am doing wring in my Code below? I could download file size 
less than 7MB.

A few notes about our shared envirnment:
- We are running WebSphere 6.0 on Window server
- It is a Virtual Machine
- 4 GBs on server, but is split to 4 server instance, so we have about 1 GB
- The code below is executed on WebSphere, but the file that need to be 
downloaded is on a different window server - shared server - 
//serverName/somedir/file.doc 

I would greatly appreciate any help you could offer THANKS!

Here's my code:

FileInputStream fileIn = null;
File file = null;
URL url = null;
URLConnection urlConn = null;
InputStream in = null;
PrintWriter pw = null; 
try{
file = new File(\\serverPath\download\documents\test.doc); 

if(file.exists() == true){ 
LOG.debug(file exists...); 

//generate URL for file 
url = file.toURL(); 
urlConn = url.openConnection(); 
in = url.openStream();

fileIn = new FileInputStream(file); 

response.setContentType(urlConn.getContentType()); 
response.setHeader(Content-Disposition,inline; filename=\ + file.getName() 
+ \);

LOG.debug(urlConn.getContentType() =  + urlConn.getContentType());

long startTime = System.currentTimeMillis(); 

IOUtils.copy(fileIn, response.getOutputStream());
response.setStatus(response.SC_OK);
response.flushBuffer(); 

LOG.debug(Total Time Taken to download: +(System.currentTimeMillis() - 
startTime) +  ms); renderFileFlag = true; 

}else{ 
LOG.debug(file not found...); 
} 
} catch (FileNotFoundExceptione) { 
LOG.error(FileNotFoundExceptione: download -  + e.getMessage(), e);

} catch (IOExceptione) { 
LOG.error(IOException: download -  + e.getMessage(), e); 

} catch (Exception e) { 
LOG.error(Exception : download -  + e.getMessage(), e);

} finally { 
if (facesContext != null) facesContext = null; 
if (fileIn != null) fileIn.close(); 
if (file != null) file = null; 
if (url != null) url = null;
if (urlConn != null) urlConn = null;
if (in != null) in.close(); 
if (pw != null) pw.close();
} 


-
Ahhh...imagining that irresistible new car smell?
Check out new cars at Yahoo! Autos. 


-
Ahhh...imagining that irresistible new car smell?
Check outnew cars at Yahoo! Autos.

   
-
Ahhh...imagining that irresistible new car smell?
 Check outnew cars at Yahoo! Autos.

java.lang.OutOfMemoryError - IOUtils.copy - When file size larger than 7 MB

2007-04-25 Thread Bibs L
Hi,
  
I am stuck with a java.lang.OutOfMemoryError when I try to copy a file 
of about 7 MB from a window server. I am using the 
org.apache.commons.io.IOUtils, 
IOUtils.copy(fileIn, response.getOutputStream()) with Survlet response 
to get the download diaglog to pop up.

This is working fine when I run it locally - (download file larger than 
7MB), but when I deploy the code to Shaed Environment- (download the 
SAME file larger than 7MB), it is throwing java.lang.OutOfMemoryError 
Exception. And evertime it throw the OutOfMemoryError, it creates a 
heapdump.phd file and a javacore File on the shared environemnt's profile 
location. 

Does anyone know what I need to do to fix this issue? 

The only thing I could think of is that the memory is low on the 
server, do we need to increase the JVM heap? What's the down side to that? 
Is it something I am doing wring in my Code below? I could download 
file size less than 7MB.

A few notes about our shared envirnment:
- We are running WebSphere 6.0 on Window server
- It is a Virtual Machine
- 4 GBs on server, but is split to 4 server instance, so we have about 
1 GB
- The code below is executed on WebSphere, but the file that need to be 
downloaded is on a different window server - shared server - 
//serverName/somedir/file.doc 

I would greatly appreciate any help you could offer 
THANKS!

Here's my code:

FileInputStream fileIn = null;
File file = null;
URL url = null;
URLConnection urlConn = null;
InputStream in = null;
PrintWriter pw = null; 
try{
file = new File(\\serverPath\download\documents\test.doc); 

if(file.exists() == true){ 
LOG.debug(file exists...); 

//generate URL for file 
url = file.toURL(); 
urlConn = url.openConnection(); 
in = url.openStream();

fileIn = new FileInputStream(file); 

response.setContentType(urlConn.getContentType()); 
response.setHeader(Content-Disposition,inline; filename=\ + 
file.getName() + \);

LOG.debug(urlConn.getContentType() =  + urlConn.getContentType());

long startTime = System.currentTimeMillis(); 

IOUtils.copy(fileIn, response.getOutputStream());
response.setStatus(response.SC_OK);
response.flushBuffer(); 

LOG.debug(Total Time Taken to download: +(System.currentTimeMillis() 
- startTime) +  ms); renderFileFlag = true; 

}else{ 
LOG.debug(file not found...); 
} 
} catch (FileNotFoundExceptione) { 
LOG.error(FileNotFoundExceptione: download -  + e.getMessage(), e);

} catch (IOExceptione) { 
LOG.error(IOException: download -  + e.getMessage(), e); 

} catch (Exception e) { 
LOG.error(Exception : download -  + e.getMessage(), e);

} finally { 
if (facesContext != null) facesContext = null; 
if (fileIn != null) fileIn.close(); 
if (file != null) file = null; 
if (url != null) url = null;
if (urlConn != null) urlConn = null;
if (in != null) in.close(); 
if (pw != null) pw.close();
} 


   
-
Ahhh...imagining that irresistible new car smell?
 Check outnew cars at Yahoo! Autos.

svn commit: r532523 - /jakarta/commons/proper/commons-parent/trunk/pom.xml

2007-04-25 Thread niallp
Author: niallp
Date: Wed Apr 25 16:10:06 2007
New Revision: 532523

URL: http://svn.apache.org/viewvc?view=revrev=532523
Log:
Specify maven source plugin version 2.0.3 and remove antrun workaround for 
source plugin bug (now resolved)

Modified:
jakarta/commons/proper/commons-parent/trunk/pom.xml

Modified: jakarta/commons/proper/commons-parent/trunk/pom.xml
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/commons-parent/trunk/pom.xml?view=diffrev=532523r1=532522r2=532523
==
--- jakarta/commons/proper/commons-parent/trunk/pom.xml (original)
+++ jakarta/commons/proper/commons-parent/trunk/pom.xml Wed Apr 25 16:10:06 2007
@@ -96,6 +96,16 @@
 /mailingList
   /mailingLists
   build
+resources
+  resource
+directory${basedir}/directory
+targetPathMETA-INF/targetPath
+includes
+  includeNOTICE.txt/include
+  includeLICENSE.txt/include
+/includes
+  /resource
+/resources
 pluginManagement
   plugins
 plugin
@@ -108,6 +118,11 @@
   artifactIdmaven-jar-plugin/artifactId
   version2.1/version
 /plugin
+plugin
+  groupIdorg.apache.maven.plugins/groupId
+  artifactIdmaven-source-plugin/artifactId
+  version2.0.3/version
+/plugin
   /plugins
 /pluginManagement
 plugins
@@ -143,35 +158,6 @@
   jdkLevel${maven.compile.source}/jdkLevel
 /configuration
   /plugin
-  plugin
-!-- This should possibly better be done by using a resource
- definition. However, if we declare a resource with
- ${basedir} as the base directory, then the
- maven-source-plugin will add the whole directory to
- its contents when generating a sources jar.
-
- see http://jira.codehaus.org/browse/MSOURCES-6
---
-artifactIdmaven-antrun-plugin/artifactId
-executions
-  execution
-phasegenerate-resources/phase
-configuration
-  tasks
-copy todir=${project.build.outputDirectory}/META-INF
-  fileset dir=${basedir}
-include name=LICENSE.txt /
-include name=NOTICE.txt /
-  /fileset
-/copy
-  /tasks
-/configuration
-goals
-  goalrun/goal
-/goals
-  /execution
-/executions
-  /plugin
 /plugins
   /build
 
@@ -230,6 +216,15 @@
 /repository
   /distributionManagement
   build
+pluginManagement
+  plugins
+plugin
+  groupIdorg.apache.maven.plugins/groupId
+  artifactIdmaven-source-plugin/artifactId
+  version2.0.3/version
+/plugin
+  /plugins
+/pluginManagement
 plugins
   !-- We want to sign the artifact, the POM, and all attached 
artifacts --
   plugin
@@ -290,6 +285,15 @@
 /snapshotRepository
   /distributionManagement
   build
+pluginManagement
+  plugins
+plugin
+  groupIdorg.apache.maven.plugins/groupId
+  artifactIdmaven-source-plugin/artifactId
+  version2.0.3/version
+/plugin
+  /plugins
+/pluginManagement
 plugins
   !-- We want to sign the artifact, the POM, and all attached 
artifacts --
   plugin



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



Re: [sandbox] releasing parent sandbox pom

2007-04-25 Thread Niall Pemberton

On 4/25/07, Carlos Sanchez [EMAIL PROTECTED] wrote:

the source plugin 2.0.3 was just released, can we go ahead?


I've just updated the commons-parent pom for the 2.0.3 source plugin -
so OK by me.

http://svn.apache.org/viewvc?view=revrevision=532523

Niall


On 3/17/07, Niall Pemberton [EMAIL PROTECTED] wrote:
 On 3/17/07, Carlos Sanchez [EMAIL PROTECTED] wrote:
  can the parent commons-sandbox be released so all sandbox components
  can be built by themselves?
  it just needs to have the parent version updated to 2
 
  or even better if commons parent is also released to take advantage of
  latest changes before releasing sandbox parent.

 I was hoping the maven source plugin was going to get a release - so
 that we could remove the antrun workaround for the source plugin bug -
 then release a new commons parent. Unfortunately that seems to be
 stalled on the maven list.

 Niall

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




--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
 -- The Princess Bride

-
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: [sandbox] releasing parent sandbox pom

2007-04-25 Thread Carlos Sanchez

then we'd need a release of the parent and then one of the sandbox parent

On 4/25/07, Niall Pemberton [EMAIL PROTECTED] wrote:

On 4/25/07, Carlos Sanchez [EMAIL PROTECTED] wrote:
 the source plugin 2.0.3 was just released, can we go ahead?

I've just updated the commons-parent pom for the 2.0.3 source plugin -
so OK by me.

http://svn.apache.org/viewvc?view=revrevision=532523

Niall

 On 3/17/07, Niall Pemberton [EMAIL PROTECTED] wrote:
  On 3/17/07, Carlos Sanchez [EMAIL PROTECTED] wrote:
   can the parent commons-sandbox be released so all sandbox components
   can be built by themselves?
   it just needs to have the parent version updated to 2
  
   or even better if commons parent is also released to take advantage of
   latest changes before releasing sandbox parent.
 
  I was hoping the maven source plugin was going to get a release - so
  that we could remove the antrun workaround for the source plugin bug -
  then release a new commons parent. Unfortunately that seems to be
  stalled on the maven list.
 
  Niall
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 


 --
 I could give you my word as a Spaniard.
 No good. I've known too many Spaniards.
  -- The Princess Bride

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





--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride

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



[jira] Updated: (CONFIGURATION-211) CommandLineConfiguration

2007-04-25 Thread Emmanuel Bourg (JIRA)

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

Emmanuel Bourg updated CONFIGURATION-211:
-

Attachment: CommandLineConfiguration.java

This is another implementation derived from my previous class :
- the remaining arguments are added to the configuration under the 
CommandLineConfiguration.PARAMETERS_KEY
- properties can be specified as -key=value and --key=value
- the value is optional, -key is considered as a boolean flag
- a no arg constructor is present, allowing a change of the list delimiter 
before parsing the arguments



 CommandLineConfiguration
 

 Key: CONFIGURATION-211
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-211
 Project: Commons Configuration
  Issue Type: Improvement
Affects Versions: Nightly Builds
Reporter: Emmanuel Bourg
Priority: Minor
 Fix For: 1.5

 Attachments: CLI-CommandLineConfiguration.java, 
 CommandLineConfiguration.java, CommandLineConfiguration.java, 
 TestCommandLineConfiguration.java


 I implemented a simple configuration taking the properties from the command
 line. I don't know if it is worth adding in the main code base, but I'm
 submitting it here if ever someone find it useful. Comments are welcome :)

-- 
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: [sandbox] releasing parent sandbox pom

2007-04-25 Thread Niall Pemberton

On 4/26/07, Carlos Sanchez [EMAIL PROTECTED] wrote:

then we'd need a release of the parent and then one of the sandbox parent


Do we need a Sandbox pom any more? Can't sandbox components use commons-parent?

Niall


On 4/25/07, Niall Pemberton [EMAIL PROTECTED] wrote:
 On 4/25/07, Carlos Sanchez [EMAIL PROTECTED] wrote:
  the source plugin 2.0.3 was just released, can we go ahead?

 I've just updated the commons-parent pom for the 2.0.3 source plugin -
 so OK by me.

 http://svn.apache.org/viewvc?view=revrevision=532523

 Niall

  On 3/17/07, Niall Pemberton [EMAIL PROTECTED] wrote:
   On 3/17/07, Carlos Sanchez [EMAIL PROTECTED] wrote:
can the parent commons-sandbox be released so all sandbox components
can be built by themselves?
it just needs to have the parent version updated to 2
   
or even better if commons parent is also released to take advantage of
latest changes before releasing sandbox parent.
  
   I was hoping the maven source plugin was going to get a release - so
   that we could remove the antrun workaround for the source plugin bug -
   then release a new commons parent. Unfortunately that seems to be
   stalled on the maven list.
  
   Niall
  
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
 
 
  --
  I could give you my word as a Spaniard.
  No good. I've known too many Spaniards.
   -- The Princess Bride
 
  -
  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]




--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
 -- The Princess Bride

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



svn commit: r532554 - /jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/beanutils/ConfigurationDynaBean.java

2007-04-25 Thread ebourg
Author: ebourg
Date: Wed Apr 25 17:40:17 2007
New Revision: 532554

URL: http://svn.apache.org/viewvc?view=revrev=532554
Log:
Code simplification in ConfigurationDynaBean
ConfigurationDynaBean.set(String, Object) supports Collection values
Fixed a potential ClassCastException in ConfigurationDynaBean(String, int, 
Object) for arrays of primitives

Modified:

jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/beanutils/ConfigurationDynaBean.java

Modified: 
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/beanutils/ConfigurationDynaBean.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/beanutils/ConfigurationDynaBean.java?view=diffrev=532554r1=532553r2=532554
==
--- 
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/beanutils/ConfigurationDynaBean.java
 (original)
+++ 
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/beanutils/ConfigurationDynaBean.java
 Wed Apr 25 17:40:17 2007
@@ -17,6 +17,8 @@
 
 package org.apache.commons.configuration.beanutils;
 
+import java.lang.reflect.Array;
+import java.util.Collection;
 import java.util.Iterator;
 import java.util.List;
 
@@ -26,7 +28,6 @@
 import org.apache.commons.configuration.ConfigurationMap;
 import org.apache.commons.configuration.ConversionException;
 import org.apache.commons.configuration.SubsetConfiguration;
-import org.apache.commons.lang.BooleanUtils;
 import org.apache.commons.logging.Log;
 import org.apache.commons.logging.LogFactory;
 
@@ -65,6 +66,7 @@
 /**
  * Creates a new instance of codeConfigurationDynaBean/code and sets
  * the configuration this bean is associated with.
+ *
  * @param configuration the configuration
  */
 public ConfigurationDynaBean(Configuration configuration)
@@ -88,85 +90,21 @@
 throw new NullPointerException(Error trying to set property to 
null.);
 }
 
-if (value instanceof List)
+if (value instanceof Collection)
 {
-List list = (List) value;
-Iterator iterator = list.iterator();
+Collection collection = (Collection) value;
+Iterator iterator = collection.iterator();
 while (iterator.hasNext())
 {
 getConfiguration().addProperty(name, iterator.next());
 }
 }
-else if (value instanceof int[])
+else if (value.getClass().isArray())
 {
-int[] array = (int[]) value;
-for (int i = 0; i  array.length; i++)
+int length = Array.getLength(value);
+for (int i = 0; i  length; i++)
 {
-getConfiguration().addProperty(name, new Integer(array[i]));
-}
-}
-else if (value instanceof boolean[])
-{
-boolean[] array = (boolean[]) value;
-for (int i = 0; i  array.length; i++)
-{
-getConfiguration().addProperty(name, 
BooleanUtils.toBooleanObject(array[i]));
-}
-}
-else if (value instanceof char[])
-{
-char[] array = (char[]) value;
-for (int i = 0; i  array.length; i++)
-{
-getConfiguration().addProperty(name, new Character(array[i]));
-}
-}
-else if (value instanceof byte[])
-{
-byte[] array = (byte[]) value;
-for (int i = 0; i  array.length; i++)
-{
-getConfiguration().addProperty(name, new Byte(array[i]));
-}
-}
-else if (value instanceof short[])
-{
-short[] array = (short[]) value;
-for (int i = 0; i  array.length; i++)
-{
-getConfiguration().addProperty(name, new Short(array[i]));
-}
-}
-else if (value instanceof long[])
-{
-long[] array = (long[]) value;
-for (int i = 0; i  array.length; i++)
-{
-getConfiguration().addProperty(name, new Long(array[i]));
-}
-}
-else if (value instanceof float[])
-{
-float[] array = (float[]) value;
-for (int i = 0; i  array.length; i++)
-{
-getConfiguration().addProperty(name, new Float(array[i]));
-}
-}
-else if (value instanceof double[])
-{
-double[] array = (double[]) value;
-for (int i = 0; i  array.length; i++)
-{
-getConfiguration().addProperty(name, new Double(array[i]));
-}
-}
-else if (value instanceof Object[])
-{
-Object[] array = (Object[]) value;
-for (int 

Re: [sandbox] releasing parent sandbox pom

2007-04-25 Thread Carlos Sanchez

i guess at least to override the repo and prevent releases being deployed

On 4/25/07, Niall Pemberton [EMAIL PROTECTED] wrote:

On 4/26/07, Carlos Sanchez [EMAIL PROTECTED] wrote:
 then we'd need a release of the parent and then one of the sandbox parent

Do we need a Sandbox pom any more? Can't sandbox components use commons-parent?

Niall

 On 4/25/07, Niall Pemberton [EMAIL PROTECTED] wrote:
  On 4/25/07, Carlos Sanchez [EMAIL PROTECTED] wrote:
   the source plugin 2.0.3 was just released, can we go ahead?
 
  I've just updated the commons-parent pom for the 2.0.3 source plugin -
  so OK by me.
 
  http://svn.apache.org/viewvc?view=revrevision=532523
 
  Niall
 
   On 3/17/07, Niall Pemberton [EMAIL PROTECTED] wrote:
On 3/17/07, Carlos Sanchez [EMAIL PROTECTED] wrote:
 can the parent commons-sandbox be released so all sandbox components
 can be built by themselves?
 it just needs to have the parent version updated to 2

 or even better if commons parent is also released to take advantage of
 latest changes before releasing sandbox parent.
   
I was hoping the maven source plugin was going to get a release - so
that we could remove the antrun workaround for the source plugin bug -
then release a new commons parent. Unfortunately that seems to be
stalled on the maven list.
   
Niall
   
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
   
   
  
  
   --
   I could give you my word as a Spaniard.
   No good. I've known too many Spaniards.
-- The Princess Bride
  
   -
   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]
 
 


 --
 I could give you my word as a Spaniard.
 No good. I've known too many Spaniards.
  -- The Princess Bride

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





--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride

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