svn commit: r555184 - in /jakarta/commons/proper/beanutils/trunk: pom.xml src/test/org/apache/commons/beanutils/PropertyUtilsTestCase.java
Author: niallp
Date: Tue Jul 10 23:25:35 2007
New Revision: 555184
URL: http://svn.apache.org/viewvc?view=revrev=555184
Log:
correct test failing in JDK 1.6
Modified:
jakarta/commons/proper/beanutils/trunk/pom.xml
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/PropertyUtilsTestCase.java
Modified: jakarta/commons/proper/beanutils/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/beanutils/trunk/pom.xml?view=diffrev=555184r1=555183r2=555184
==
--- jakarta/commons/proper/beanutils/trunk/pom.xml (original)
+++ jakarta/commons/proper/beanutils/trunk/pom.xml Tue Jul 10 23:25:35 2007
@@ -22,7 +22,7 @@
parent
groupIdorg.apache.commons/groupId
artifactIdcommons-parent/artifactId
-version1/version
+version3/version
/parent
modelVersion4.0.0/modelVersion
groupIdcommons-beanutils/groupId
Modified:
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/PropertyUtilsTestCase.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/PropertyUtilsTestCase.java?view=diffrev=555184r1=555183r2=555184
==
---
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/PropertyUtilsTestCase.java
(original)
+++
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/PropertyUtilsTestCase.java
Tue Jul 10 23:25:35 2007
@@ -4252,7 +4252,8 @@
assertNotNull(Cause not found, cause);
assertTrue(Expected cause to be IllegalArgumentException, but
was: + cause.getClass(),
cause instanceof IllegalArgumentException);
-assertEquals(Check error message, argument type mismatch,
cause.getMessage());
+// JDK 1.6 doesn't have argument type mismatch message
+// assertEquals(Check error message, argument type mismatch,
cause.getMessage());
} catch(Throwable t) {
fail(Expected IllegalArgumentException, but threw + t);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-18) [beanutils] PropertyUtils.isReadable() and PropertyUtils.getProperty() not consistent
[ https://issues.apache.org/jira/browse/BEANUTILS-18?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-18: - Attachment: BEANUTILS-18-PropertyUtilsBean.patch As well as PropertyUtilsBean's isReadable() and isWriteable() methods the indexed and mapped get/set methods are also missing the checks that the simple get/set methods use. Attaching a patch for review [beanutils] PropertyUtils.isReadable() and PropertyUtils.getProperty() not consistent - Key: BEANUTILS-18 URL: https://issues.apache.org/jira/browse/BEANUTILS-18 Project: Commons BeanUtils Issue Type: Bug Components: Bean / Property Utils Environment: Operating System: Windows 2000 Platform: PC Reporter: Maarten Coene Fix For: 1.8.0 Attachments: BEANUTILS-18-PropertyUtilsBean.patch, patch-PropertyUtilsBean.txt, patch-PropertyUtilsTestCase.txt, PropertyUtilsTest.java Hi, When the object passed to PropertyUtils is a non-public class, the PropertyUtils.isReadable() method returns true for an existing property while the PropertyUtils.getProperty() method for the same property throws a NoSuchMethodException. I'll attach a junit test that illustrates the problem. regards, Maarten -- 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: (COLLECTIONS-259) TransformerClosure should implement Transformer and allow extension.
[
https://issues.apache.org/jira/browse/COLLECTIONS-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511686
]
Stephen Colebourne commented on COLLECTIONS-259:
An interesting idea, however I sense that it might confuse the intent of the
class for a limited use case.
TransformerClosure should implement Transformer and allow extension.
Key: COLLECTIONS-259
URL: https://issues.apache.org/jira/browse/COLLECTIONS-259
Project: Commons Collections
Issue Type: Improvement
Components: Functor
Affects Versions: 3.2
Reporter: Stephen Kestle
Priority: Minor
Fix For: 3.3, Generics
TransformerClosure currently decorates a transformer. However, in the
interests of non-verbose code, it makes sense to be able to subclass it for a
class that implements both interfaces.
I propose the addition of the following constructor and method
protected TransformerClosure(){
iTransformer = this;
}
public O transform(I in){
return iTransformer.transform();
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LOGGING-114) Silent Swallowing of NoClassDefFoundError
[ https://issues.apache.org/jira/browse/LOGGING-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511699 ] Malcolm Cleaton commented on LOGGING-114: - Hi Dennis. Yes, log4j does usually tell you when it cannot load its configuration. In this case it tells me through a NoClassDefFoundError when runtime dependencies fail to load during configuration loading. If commons-logging is not in use, the error is easy to understand and quickly fixed. Unfortunately, if commons-logging is the first to try to load log4j, the error is swallowed silently. Since it is a problem during the clinint of the LogManager class, log4j is now broken internally and will not give good errors again - any future use gets incomprehensible errors. What's more, if commons-logging diagnostics are enabled, the diagnostic error is logged with most of the information missing. But I'm repeating myself here, all this is in the bug report, along with the actual messages involved. To understand my problem, imagine the other side of it, which will probably shortly be happening - imagine my attempts to file a bug in log4j on the basis that, if a class can't be found during configuration loading, they simply allow the NoClassDefFoundError to propagate. How is that wrong? But if you're adamant that silently swallowing this error is also not wrong, it's not their problem and it's not your problem. Where does that leave the user? I guess it's just my problem. Silent Swallowing of NoClassDefFoundError - Key: LOGGING-114 URL: https://issues.apache.org/jira/browse/LOGGING-114 Project: Commons Logging Issue Type: Bug Affects Versions: 1.1.0 Environment: Various OSs, in combination with log4j 1.2.14. Reporter: Malcolm Cleaton Priority: Minor Hi. I'm using commons logging with log4j; my team ship a library which uses log4j, and some of our clients use it with commons-logging. If commons-logging is in its default configuration, and log4j is present but fails to load its configuration with an unhandled exception, the results are pretty nasty: - commons-logging silently swallows the exception and logs with something else. If diagnostics are turned on, the message is: Could not instantiate Log 'org.apache.commons.logging.impl.Log4JLogger' -- java.lang.reflect.InvocationTargetException: null - future attempts to use log4j directly get a pretty unhelpful error: java.lang.NoClassDefFoundError at org.apache.log4j.Logger.getLogger(Logger.java:117). I realise you're trying to deal with a very large number of cases in this code, but it does seem like something better could be done here. If nothing else is possible, at least recognising the InvocationTargetException and pulling out the target exception for the diagnostic log would have helped with tracking this one down. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LOGGING-114) Silent Swallowing of NoClassDefFoundError
[ https://issues.apache.org/jira/browse/LOGGING-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511709 ] Joerg Schaible commented on LOGGING-114: IMHO this is really a JCL problem. It detects log4j and tries to use it. It is fine that it searches for something else if log4j is not present. But here it even suppresses a thrown Error that indicates also a problem for JCL. From user's PoV either the presence of log4j was not expected at all, he failed to configure to Log4J or he failed to configure JCL. In any case he must realize that something is not working as expected. Silent Swallowing of NoClassDefFoundError - Key: LOGGING-114 URL: https://issues.apache.org/jira/browse/LOGGING-114 Project: Commons Logging Issue Type: Bug Affects Versions: 1.1.0 Environment: Various OSs, in combination with log4j 1.2.14. Reporter: Malcolm Cleaton Priority: Minor Hi. I'm using commons logging with log4j; my team ship a library which uses log4j, and some of our clients use it with commons-logging. If commons-logging is in its default configuration, and log4j is present but fails to load its configuration with an unhandled exception, the results are pretty nasty: - commons-logging silently swallows the exception and logs with something else. If diagnostics are turned on, the message is: Could not instantiate Log 'org.apache.commons.logging.impl.Log4JLogger' -- java.lang.reflect.InvocationTargetException: null - future attempts to use log4j directly get a pretty unhelpful error: java.lang.NoClassDefFoundError at org.apache.log4j.Logger.getLogger(Logger.java:117). I realise you're trying to deal with a very large number of cases in this code, but it does seem like something better could be done here. If nothing else is possible, at least recognising the InvocationTargetException and pulling out the target exception for the diagnostic log would have helped with tracking this one down. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (CONFIGURATION-285) configuration fileName=local-configuration.xml config-optional=true / does not report parsing errors in local-configuration.xml
configuration fileName=local-configuration.xml config-optional=true / does not report parsing errors in local-configuration.xml - Key: CONFIGURATION-285 URL: https://issues.apache.org/jira/browse/CONFIGURATION-285 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.4 Reporter: Thorbjørn Ravn Andersen I'm trying to build a configuration system to be shared between our Java applications. I therefore want to have optional configurations included from the main configuration file read by DefaultConfigurationBuilder configuration fileName=local-configuration.xml config-optional=true / I have found that if the sub-configuration file is invalid the error is silently ignored. The same without config-options=true results in a ConfigurationException to be thrown (which wraps a ConfigurationRuntimeException which wraps the ConfigurationException which wraps the SAXException). I believe that the behaviour is incorrect. The sub-configuration file should be skipped if not found, but any errors found when parsing the existing file should be logged. -- 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]
Commons Math, Commons Nightlies, vmbuild
Hi, This is particularly for Phil and those on commons-math, but if anyone else is interested in getting set up just holler. commons-math currently have a build set up in vmbuild.apache.org. It's been down for little bit, but is now back up. vmbuild is scheduled to be moved to a faster machine, and I intend to install a more recent build of Continuum (that supports grouping projects and is generally faster, more managable and more stable). I'm able to help get it set up as effectively as possible. There are a lot of failing builds on the machine right now (probably unused by the corresponding projects), so I'm cleaning house before the move. Please let me know if: [ ] you would like the project set up on the new machine with a clean slate [ ] you would like the project (and it's build history if possible) moved over [ ] you are no longer interested in using vmbuild for CI/nightlies/ whatever In addition, the commons nightlies scripts will need to be moved along with the VM, but since we will probably start with a clean slate I might need a hand with that. Thanks! - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JXPATH-95) Comparing with NaN is incorrect
Comparing with NaN is incorrect --- Key: JXPATH-95 URL: https://issues.apache.org/jira/browse/JXPATH-95 Project: Commons JXPath Issue Type: Bug Reporter: Sergey Vladimirov 'NaN' 'NaN' is true, but should be FALSE -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JXPATH-95) Comparing with NaN is incorrect
[ https://issues.apache.org/jira/browse/JXPATH-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Benson updated JXPATH-95: -- Fix Version/s: 1.3 Affects Version/s: Nightly Builds Comparing with NaN is incorrect --- Key: JXPATH-95 URL: https://issues.apache.org/jira/browse/JXPATH-95 Project: Commons JXPath Issue Type: Bug Affects Versions: Nightly Builds Reporter: Sergey Vladimirov Fix For: 1.3 'NaN' 'NaN' is true, but should be FALSE -- 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: r555334 - in /jakarta/commons/proper/jxpath/trunk/src: java/org/apache/commons/jxpath/ri/compiler/CoreOperationRelationalExpression.java test/org/apache/commons/jxpath/ri/compiler/CoreOper
Author: mbenson
Date: Wed Jul 11 09:44:01 2007
New Revision: 555334
URL: http://svn.apache.org/viewvc?view=revrev=555334
Log:
[JXPATH-95] fix NaN comparisons
Modified:
jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/compiler/CoreOperationRelationalExpression.java
jakarta/commons/proper/jxpath/trunk/src/test/org/apache/commons/jxpath/ri/compiler/CoreOperationTest.java
Modified:
jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/compiler/CoreOperationRelationalExpression.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/compiler/CoreOperationRelationalExpression.java?view=diffrev=555334r1=555333r2=555334
==
---
jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/compiler/CoreOperationRelationalExpression.java
(original)
+++
jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/compiler/CoreOperationRelationalExpression.java
Wed Jul 11 09:44:01 2007
@@ -72,7 +72,15 @@
if (right instanceof Iterator) {
return containsMatch((Iterator) right, left);
}
-return evaluateCompare(compare(left, right));
+double ld = InfoSetUtil.doubleValue(left);
+if (Double.isNaN(ld)) {
+return false;
+}
+double rd = InfoSetUtil.doubleValue(right);
+if (Double.isNaN(rd)) {
+return false;
+}
+return evaluateCompare(ld == rd ? 0 : ld rd ? -1 : 1);
}
private Object reduce(Object o) {
@@ -88,7 +96,7 @@
private boolean containsMatch(Iterator it, Object value) {
while (it.hasNext()) {
Object element = it.next();
-if (evaluateCompare(compare(element, value))) {
+if (compute(element, value)) {
return true;
}
}
@@ -106,12 +114,6 @@
}
}
return false;
-}
-
-private int compare(Object l, Object r) {
-double ld = InfoSetUtil.doubleValue(l);
-double rd = InfoSetUtil.doubleValue(r);
-return ld == rd ? 0 : ld rd ? -1 : 1;
}
}
Modified:
jakarta/commons/proper/jxpath/trunk/src/test/org/apache/commons/jxpath/ri/compiler/CoreOperationTest.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/jxpath/trunk/src/test/org/apache/commons/jxpath/ri/compiler/CoreOperationTest.java?view=diffrev=555334r1=555333r2=555334
==
---
jakarta/commons/proper/jxpath/trunk/src/test/org/apache/commons/jxpath/ri/compiler/CoreOperationTest.java
(original)
+++
jakarta/commons/proper/jxpath/trunk/src/test/org/apache/commons/jxpath/ri/compiler/CoreOperationTest.java
Wed Jul 11 09:44:01 2007
@@ -46,6 +46,7 @@
Variables vars = context.getVariables();
vars.declareVariable(integer, new Integer(1));
vars.declareVariable(array, new double[] { 0.25, 0.5, 0.75 });
+vars.declareVariable(nan, new Double(Double.NaN));
}
}
@@ -109,5 +110,17 @@
assertXPathValue(context, $array = 1, Boolean.FALSE, Boolean.class);
assertXPathValue(context, $array 1, Boolean.FALSE, Boolean.class);
assertXPathValue(context, $array 0, Boolean.FALSE, Boolean.class);
+}
+
+public void testNan() {
+assertXPathValue(context, $nan $nan, Boolean.FALSE, Boolean.class);
+assertXPathValue(context, $nan $nan, Boolean.FALSE, Boolean.class);
+assertXPathValue(context, $nan = $nan, Boolean.TRUE, Boolean.class);
+assertXPathValue(context, $nan 0, Boolean.FALSE, Boolean.class);
+assertXPathValue(context, $nan 0, Boolean.FALSE, Boolean.class);
+assertXPathValue(context, $nan = 0, Boolean.FALSE, Boolean.class);
+assertXPathValue(context, $nan 1, Boolean.FALSE, Boolean.class);
+assertXPathValue(context, $nan 1, Boolean.FALSE, Boolean.class);
+assertXPathValue(context, $nan = 1, Boolean.FALSE, Boolean.class);
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r555336 - /jakarta/commons/proper/jxpath/trunk/src/test/org/apache/commons/jxpath/ri/compiler/CoreOperationTest.java
Author: mbenson
Date: Wed Jul 11 09:49:15 2007
New Revision: 555336
URL: http://svn.apache.org/viewvc?view=revrev=555336
Log:
more tests
Modified:
jakarta/commons/proper/jxpath/trunk/src/test/org/apache/commons/jxpath/ri/compiler/CoreOperationTest.java
Modified:
jakarta/commons/proper/jxpath/trunk/src/test/org/apache/commons/jxpath/ri/compiler/CoreOperationTest.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/jxpath/trunk/src/test/org/apache/commons/jxpath/ri/compiler/CoreOperationTest.java?view=diffrev=555336r1=555335r2=555336
==
---
jakarta/commons/proper/jxpath/trunk/src/test/org/apache/commons/jxpath/ri/compiler/CoreOperationTest.java
(original)
+++
jakarta/commons/proper/jxpath/trunk/src/test/org/apache/commons/jxpath/ri/compiler/CoreOperationTest.java
Wed Jul 11 09:49:15 2007
@@ -115,12 +115,25 @@
public void testNan() {
assertXPathValue(context, $nan $nan, Boolean.FALSE, Boolean.class);
assertXPathValue(context, $nan $nan, Boolean.FALSE, Boolean.class);
+assertXPathValue(context, $nan = $nan, Boolean.FALSE,
Boolean.class);
+assertXPathValue(context, $nan = $nan, Boolean.FALSE,
Boolean.class);
+//note that = and = implies a test of numerical, rather than
object, equality. ;)
+assertXPathValue(context, $nan = $nan and $nan = $nan,
Boolean.FALSE, Boolean.class);
assertXPathValue(context, $nan = $nan, Boolean.TRUE, Boolean.class);
+assertXPathValue(context, $nan != $nan, Boolean.FALSE,
Boolean.class);
assertXPathValue(context, $nan 0, Boolean.FALSE, Boolean.class);
assertXPathValue(context, $nan 0, Boolean.FALSE, Boolean.class);
+assertXPathValue(context, $nan = 0, Boolean.FALSE, Boolean.class);
+assertXPathValue(context, $nan = 0, Boolean.FALSE, Boolean.class);
+assertXPathValue(context, $nan = 0 and $nan = 0, Boolean.FALSE,
Boolean.class);
assertXPathValue(context, $nan = 0, Boolean.FALSE, Boolean.class);
+assertXPathValue(context, $nan != 0, Boolean.TRUE, Boolean.class);
assertXPathValue(context, $nan 1, Boolean.FALSE, Boolean.class);
assertXPathValue(context, $nan 1, Boolean.FALSE, Boolean.class);
+assertXPathValue(context, $nan = 1, Boolean.FALSE, Boolean.class);
+assertXPathValue(context, $nan = 1, Boolean.FALSE, Boolean.class);
+assertXPathValue(context, $nan = 1 and $nan = 1, Boolean.FALSE,
Boolean.class);
assertXPathValue(context, $nan = 1, Boolean.FALSE, Boolean.class);
+assertXPathValue(context, $nan != 1, Boolean.TRUE, Boolean.class);
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (JXPATH-95) Comparing with NaN is incorrect
[ https://issues.apache.org/jira/browse/JXPATH-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Benson resolved JXPATH-95. --- Resolution: Fixed Whoops! Never screwed around with NaN before, apparently... Thanks for the catch, fixed in trunk. :) Comparing with NaN is incorrect --- Key: JXPATH-95 URL: https://issues.apache.org/jira/browse/JXPATH-95 Project: Commons JXPath Issue Type: Bug Affects Versions: Nightly Builds Reporter: Sergey Vladimirov Fix For: 1.3 'NaN' 'NaN' is true, but should be FALSE -- 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]
new VFS provider
I'm interested in implementing a JDBC based provider that also maintains a local (Disk FS based) cache of the files as well. Is there any documentation on implementing a new provider for VFS? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons Math, Commons Nightlies, vmbuild
Brett Porter wrote: Please let me know if: [ ] you would like the project set up on the new machine with a clean slate +1 [ ] you would like the project (and it's build history if possible) moved over [ ] you are no longer interested in using vmbuild for CI/nightlies/whatever Thanks, Brett Luc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (JXPATH-95) Comparing with NaN is incorrect
[ https://issues.apache.org/jira/browse/JXPATH-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Benson resolved JXPATH-95. --- Resolution: Fixed Whew! You are keeping me on my toes, certainly! Fixed part 2 in trunk. Comparing with NaN is incorrect --- Key: JXPATH-95 URL: https://issues.apache.org/jira/browse/JXPATH-95 Project: Commons JXPath Issue Type: Bug Affects Versions: Nightly Builds Reporter: Sergey Vladimirov Fix For: 1.3 'NaN' 'NaN' is true, but should be FALSE -- 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: r555375 - in /jakarta/commons/proper/jxpath/trunk/src: java/org/apache/commons/jxpath/ri/compiler/ test/org/apache/commons/jxpath/ri/compiler/
Author: mbenson
Date: Wed Jul 11 12:29:57 2007
New Revision: 555375
URL: http://svn.apache.org/viewvc?view=revrev=555375
Log:
[JXPATH-95] part 2: fix NaN inequality comparisons
Modified:
jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/compiler/CoreOperationCompare.java
jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/compiler/CoreOperationEqual.java
jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/compiler/CoreOperationNotEqual.java
jakarta/commons/proper/jxpath/trunk/src/test/org/apache/commons/jxpath/ri/compiler/CoreOperationTest.java
Modified:
jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/compiler/CoreOperationCompare.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/compiler/CoreOperationCompare.java?view=diffrev=555375r1=555374r2=555375
==
---
jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/compiler/CoreOperationCompare.java
(original)
+++
jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/compiler/CoreOperationCompare.java
Wed Jul 11 12:29:57 2007
@@ -34,9 +34,27 @@
* @version $Revision$ $Date$
*/
public abstract class CoreOperationCompare extends CoreOperation {
+private boolean invert;
public CoreOperationCompare(Expression arg1, Expression arg2) {
+this(arg1, arg2, false);
+}
+
+protected CoreOperationCompare(Expression arg1, Expression arg2, boolean
invert) {
super(new Expression[] { arg1, arg2 });
+this.invert = invert;
+}
+
+public Object computeValue(EvalContext context) {
+return equal(context, args[0], args[1]) ? Boolean.TRUE : Boolean.FALSE;
+}
+
+protected int getPrecedence() {
+return 2;
+}
+
+protected boolean isSymmetric() {
+return true;
}
/**
@@ -110,12 +128,6 @@
}
protected boolean equal(Object l, Object r) {
-if (l instanceof Pointer r instanceof Pointer) {
-if (l.equals(r)) {
-return true;
-}
-}
-
if (l instanceof Pointer) {
l = ((Pointer) l).getValue();
}
@@ -124,21 +136,28 @@
r = ((Pointer) r).getValue();
}
-if (l == r) {
-return true;
-}
-
+boolean result;
if (l instanceof Boolean || r instanceof Boolean) {
-return (InfoSetUtil.booleanValue(l) ==
InfoSetUtil.booleanValue(r));
-}
-if (l instanceof Number || r instanceof Number) {
-return (InfoSetUtil.doubleValue(l) == InfoSetUtil.doubleValue(r));
-}
-if (l instanceof String || r instanceof String) {
-return (
-InfoSetUtil.stringValue(l).equals(InfoSetUtil.stringValue(r)));
+result = l == r || InfoSetUtil.booleanValue(l) ==
InfoSetUtil.booleanValue(r);
+} else if (l instanceof Number || r instanceof Number) {
+//if either side is NaN, no comparison returns true:
+double ld = InfoSetUtil.doubleValue(l);
+if (Double.isNaN(ld)) {
+return false;
+}
+double rd = InfoSetUtil.doubleValue(r);
+if (Double.isNaN(rd)) {
+return false;
+}
+result = ld == rd;
+} else {
+if (l instanceof String || r instanceof String) {
+l = InfoSetUtil.stringValue(l);
+r = InfoSetUtil.stringValue(r);
+}
+result = l == r || l != null l.equals(r);
}
-return l != null l.equals(r);
+return result ^ invert;
}
}
Modified:
jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/compiler/CoreOperationEqual.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/compiler/CoreOperationEqual.java?view=diffrev=555375r1=555374r2=555375
==
---
jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/compiler/CoreOperationEqual.java
(original)
+++
jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/compiler/CoreOperationEqual.java
Wed Jul 11 12:29:57 2007
@@ -16,8 +16,6 @@
*/
package org.apache.commons.jxpath.ri.compiler;
-import org.apache.commons.jxpath.ri.EvalContext;
-
/**
* Implementation of Expression for the operation =.
*
@@ -30,18 +28,6 @@
super(arg1, arg2);
}
-public Object computeValue(EvalContext context) {
-return equal(context, args[0], args[1]) ? Boolean.TRUE : Boolean.FALSE;
-}
-
-protected int getPrecedence() {
-return 2;
-}
-
-protected boolean isSymmetric() {
-
[jira] Commented: (CONFIGURATION-285) configuration fileName=local-configuration.xml config-optional=true / does not report parsing errors in local-configuration.xml
[ https://issues.apache.org/jira/browse/CONFIGURATION-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511852 ] Oliver Heger commented on CONFIGURATION-285: Just to make sure I understand your request correctly: If the config-optional attribute is set to true and loading this sub configuration causes an error, the exception should be logged. Other behavior need not be changed, correct? configuration fileName=local-configuration.xml config-optional=true / does not report parsing errors in local-configuration.xml - Key: CONFIGURATION-285 URL: https://issues.apache.org/jira/browse/CONFIGURATION-285 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.4 Reporter: Thorbjørn Ravn Andersen I'm trying to build a configuration system to be shared between our Java applications. I therefore want to have optional configurations included from the main configuration file read by DefaultConfigurationBuilder configuration fileName=local-configuration.xml config-optional=true / I have found that if the sub-configuration file is invalid the error is silently ignored. The same without config-options=true results in a ConfigurationException to be thrown (which wraps a ConfigurationRuntimeException which wraps the ConfigurationException which wraps the SAXException). I believe that the behaviour is incorrect. The sub-configuration file should be skipped if not found, but any errors found when parsing the existing file should be logged. -- 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: (LOGGING-114) Silent Swallowing of NoClassDefFoundError
[ https://issues.apache.org/jira/browse/LOGGING-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511853 ] Simon Kitching commented on LOGGING-114: JCL has adopted the principle that logging problems should never stop an app from running. In the past exceptions from logging libs were allowed through JCL in some cases and there were loud user complaints. In many cases, the users didn't actually *want* logging output anyway, and didn't know how to fix the logging problems because they were complex and involved classloaders with different classpaths etc. So now, JCL *never* fails to init. In particular, if log4j is present but cannot be initialised (eg due to classloader problems) JCL quite deliberately ignores this problem and lets the app start. If someone really does want logging output but aren't getting what they expect *then* they can turn on JCL diagnostic output to see what's happening. I don't think there is likely to be agreement for any change to JCL's behaviour for this. Writing problems stuff to stdout etc is also unacceptable when diagnostics are not enabled. Again, this can cause problems for users who don't actually care about logging output anyway. However I would agree that when diagnostics are enabled, JCL should write out the message from the original exception. If it's not doing this then I would call that a bug. Silent Swallowing of NoClassDefFoundError - Key: LOGGING-114 URL: https://issues.apache.org/jira/browse/LOGGING-114 Project: Commons Logging Issue Type: Bug Affects Versions: 1.1.0 Environment: Various OSs, in combination with log4j 1.2.14. Reporter: Malcolm Cleaton Priority: Minor Hi. I'm using commons logging with log4j; my team ship a library which uses log4j, and some of our clients use it with commons-logging. If commons-logging is in its default configuration, and log4j is present but fails to load its configuration with an unhandled exception, the results are pretty nasty: - commons-logging silently swallows the exception and logs with something else. If diagnostics are turned on, the message is: Could not instantiate Log 'org.apache.commons.logging.impl.Log4JLogger' -- java.lang.reflect.InvocationTargetException: null - future attempts to use log4j directly get a pretty unhelpful error: java.lang.NoClassDefFoundError at org.apache.log4j.Logger.getLogger(Logger.java:117). I realise you're trying to deal with a very large number of cases in this code, but it does seem like something better could be done here. If nothing else is possible, at least recognising the InvocationTargetException and pulling out the target exception for the diagnostic log would have helped with tracking this one down. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONFIGURATION-283) CombinedConfiguration doesn't take escaped characters into account.
[
https://issues.apache.org/jira/browse/CONFIGURATION-283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger updated CONFIGURATION-283:
---
Fix Version/s: 1.5
CombinedConfiguration doesn't take escaped characters into account.
---
Key: CONFIGURATION-283
URL: https://issues.apache.org/jira/browse/CONFIGURATION-283
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.4
Reporter: Franck Valentin
Fix For: 1.5
Hi,
I've tried to used CombinedConfiguration but it seems escaped characters are
not taken into account :
import org.apache.commons.configuration.CombinedConfiguration;
import org.apache.commons.configuration.ConfigurationException;
import org.apache.commons.configuration.PropertiesConfiguration;
import junit.framework.TestCase;
public class TestProp extends TestCase {
public void testprop() throws ConfigurationException {
// test.properties contains :
//without_escape=aa,bb
//with_escape=aa\,bb
//with_2escapes=aa\\,bb
String prop_filename = c:\\tmp\\test.properties;
PropertiesConfiguration properties_config = new
PropertiesConfiguration(prop_filename);
CombinedConfiguration combined_config = new
CombinedConfiguration();
combined_config.addConfiguration(properties_config);
System.out.println(Properties config);
System.out.println(properties_config.getString(without_escape));
System.out.println(properties_config.getString(with_escape));
System.out.println(properties_config.getString(with_2escapes));
System.out.println(\nCombined config);
System.out.println(combined_config.getString(without_escape));
System.out.println(combined_config.getString(with_escape));
System.out.println(combined_config.getString(with_2escapes));
}
}
Result :
-
Properties config
aa
aa,bb
aa,bb
Combined config
aa
aa
aa
Thanks !
Franck
--
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: (LOGGING-114) Silent Swallowing of NoClassDefFoundError
[ https://issues.apache.org/jira/browse/LOGGING-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511880 ] Dennis Lundberg commented on LOGGING-114: - Malcolm, Just so I understand your setup fully: Do you configure commons-logging in any way? Either via a system property or through the use of a commons-logging.properties file? If yes, please tell us how. Do you get any message from log4j, saying that it couldn't find its configuration file? If yes, what does it say. Are you sure that your code that uses commons logging is the one that causes log4j to be loaded? Or could it be that the other library of yours, that use log4j directly, is the first user? Silent Swallowing of NoClassDefFoundError - Key: LOGGING-114 URL: https://issues.apache.org/jira/browse/LOGGING-114 Project: Commons Logging Issue Type: Bug Affects Versions: 1.1.0 Environment: Various OSs, in combination with log4j 1.2.14. Reporter: Malcolm Cleaton Priority: Minor Hi. I'm using commons logging with log4j; my team ship a library which uses log4j, and some of our clients use it with commons-logging. If commons-logging is in its default configuration, and log4j is present but fails to load its configuration with an unhandled exception, the results are pretty nasty: - commons-logging silently swallows the exception and logs with something else. If diagnostics are turned on, the message is: Could not instantiate Log 'org.apache.commons.logging.impl.Log4JLogger' -- java.lang.reflect.InvocationTargetException: null - future attempts to use log4j directly get a pretty unhelpful error: java.lang.NoClassDefFoundError at org.apache.log4j.Logger.getLogger(Logger.java:117). I realise you're trying to deal with a very large number of cases in this code, but it does seem like something better could be done here. If nothing else is possible, at least recognising the InvocationTargetException and pulling out the target exception for the diagnostic log would have helped with tracking this one down. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r555436 - in /jakarta/commons/proper/beanutils/trunk: ./ optional/bean-collections/ src/main/ src/main/assembly/ src/site/ src/site/resources/ src/site/resources/images/ xdocs/images/
Author: niallp
Date: Wed Jul 11 16:32:14 2007
New Revision: 555436
URL: http://svn.apache.org/viewvc?view=revrev=555436
Log:
Update the m2 build
Added:
jakarta/commons/proper/beanutils/trunk/optional/bean-collections/pom.xml
(with props)
jakarta/commons/proper/beanutils/trunk/src/main/
jakarta/commons/proper/beanutils/trunk/src/main/assembly/
jakarta/commons/proper/beanutils/trunk/src/main/assembly/bin.xml (with
props)
jakarta/commons/proper/beanutils/trunk/src/main/assembly/src.xml (with
props)
jakarta/commons/proper/beanutils/trunk/src/site/
jakarta/commons/proper/beanutils/trunk/src/site/resources/
jakarta/commons/proper/beanutils/trunk/src/site/resources/images/
jakarta/commons/proper/beanutils/trunk/src/site/resources/images/logo.png
- copied unchanged from r555183,
jakarta/commons/proper/beanutils/trunk/xdocs/images/logo.png
Removed:
jakarta/commons/proper/beanutils/trunk/xdocs/images/
Modified:
jakarta/commons/proper/beanutils/trunk/maven.xml
jakarta/commons/proper/beanutils/trunk/pom.xml
Modified: jakarta/commons/proper/beanutils/trunk/maven.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/beanutils/trunk/maven.xml?view=diffrev=555436r1=555435r2=555436
==
--- jakarta/commons/proper/beanutils/trunk/maven.xml (original)
+++ jakarta/commons/proper/beanutils/trunk/maven.xml Wed Jul 11 16:32:14 2007
@@ -19,6 +19,13 @@
xmlns:ant=jelly:ant
xmlns:j=jelly:core
xmlns:util=jelly:util
+
+
+preGoal name=site
+copy todir=${maven.build.dir}/docs/images
+fileset dir=${basedir}/src/site/resources/images/
+/copy
+/preGoal
!-- == --
!-- Copy into the binary distribution --
Added: jakarta/commons/proper/beanutils/trunk/optional/bean-collections/pom.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/beanutils/trunk/optional/bean-collections/pom.xml?view=autorev=555436
==
--- jakarta/commons/proper/beanutils/trunk/optional/bean-collections/pom.xml
(added)
+++ jakarta/commons/proper/beanutils/trunk/optional/bean-collections/pom.xml
Wed Jul 11 16:32:14 2007
@@ -0,0 +1,109 @@
+?xml version=1.0?
+!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the License); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an AS IS BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+--
+project
+xmlns=http://maven.apache.org/POM/4.0.0;
+xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
+xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
+parent
+groupIdorg.apache.commons/groupId
+artifactIdcommons-parent/artifactId
+version3/version
+/parent
+modelVersion4.0.0/modelVersion
+groupIdcommons-beanutils/groupId
+artifactIdcommons-beanutils-bean-collections/artifactId
+version1.8.0-SNAPSHOT/version
+nameBeanUtils Bean Collections/name
+inceptionYear2000/inceptionYear
+descriptionExtensions of commons collections focussing on collections of
beans/description
+urlhttp://jakarta.apache.org/commons/beanutils//url
+issueManagement
+systemjira/system
+urlhttp://issues.apache.org/jira/browse/BEANUTILS/url
+/issueManagement
+
+scm
+
connectionscm:svn:https://svn.apache.org/repos/asf/jakarta/commons/proper/beanutils/trunk//connection
+
developerConnectionscm:svn:https://svn.apache.org/repos/asf/jakarta/commons/proper/beanutils/trunk//developerConnection
+
urlhttp://svn.apache.org/viewvc/jakarta/commons/proper/beanutils/trunk//url
+/scm
+
+dependencies
+dependency
+groupIdcommons-logging/groupId
+artifactIdcommons-logging/artifactId
+version1.0.4/version
+/dependency
+dependency
+groupIdcommons-collections/groupId
+artifactIdcommons-collections/artifactId
+version3.2/version
+/dependency
+dependency
+groupIdcommons-beanutils/groupId
+artifactIdcommons-beanutils/artifactId
+version1.8.0-SNAPSHOT/version
+
[jira] Created: (DBCP-230) [DBCP] BasicManagedDataSource
[DBCP] BasicManagedDataSource - Key: DBCP-230 URL: https://issues.apache.org/jira/browse/DBCP-230 Project: Commons Dbcp Issue Type: New Feature Reporter: Dain Sundstrom Fix For: 1.3 This patch creates an extension to the BasicDataSource which creates ManagedConnection. This class allows easy usage of the ManagedDataSource from environments that configure via JavaBeans 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]
[jira] Updated: (DBCP-230) [DBCP] BasicManagedDataSource
[ https://issues.apache.org/jira/browse/DBCP-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dain Sundstrom updated DBCP-230: Attachment: BasicManagedDataSource.patch [DBCP] BasicManagedDataSource - Key: DBCP-230 URL: https://issues.apache.org/jira/browse/DBCP-230 Project: Commons Dbcp Issue Type: New Feature Reporter: Dain Sundstrom Fix For: 1.3 Attachments: BasicManagedDataSource.patch This patch creates an extension to the BasicDataSource which creates ManagedConnection. This class allows easy usage of the ManagedDataSource from environments that configure via JavaBeans 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]
[jira] Updated: (BEANUTILS-41) Provide better error message for No value specified
[ https://issues.apache.org/jira/browse/BEANUTILS-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-41: - Issue Type: Improvement (was: Bug) Summary: Provide better error message for No value specified (was: [beanutils] Provide better error message for No value specified) Changing to improvement Provide better error message for No value specified - Key: BEANUTILS-41 URL: https://issues.apache.org/jira/browse/BEANUTILS-41 Project: Commons BeanUtils Issue Type: Improvement Components: ConvertUtils Converters Environment: Operating System: other Platform: Other Reporter: Ralf Hauser Fix For: LATER THAN 1.8.0 Got org.apache.commons.beanutils.ConversionException: No value specified at org.apache.commons.beanutils.converters.SqlDateConverter.convert(SqlDateConverter.java:103) at org.apache.commons.beanutils.BeanUtilsBean.copyProperty(BeanUtilsBean.java:444) at org.apache.commons.beanutils.BeanUtilsBean.copyProperties(BeanUtilsBean.java:261) at org.apache.commons.beanutils.BeanUtils.copyProperties(BeanUtils.java:114) Suggestion: 1) cite the propName and the bean className this probably implies that the interface org.apache.commons.beanutils.Converter.convert(Class type, Object value) is extended to org.apache.commons.beanutils.Converter.convert(Class type, Object value, String propName, String beanClassName) 2) also cite the concerned class name (probably java.sql.Date) 3) mention that there is the possibility to use a default value -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-95) Handling exceptions during BeanUtils.populate()
[ https://issues.apache.org/jira/browse/BEANUTILS-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-95: - Issue Type: Improvement (was: Bug) Summary: Handling exceptions during BeanUtils.populate() (was: [beanutils] Handling exceptions during BeanUtils.populate()) Changing to improvement Handling exceptions during BeanUtils.populate() --- Key: BEANUTILS-95 URL: https://issues.apache.org/jira/browse/BEANUTILS-95 Project: Commons BeanUtils Issue Type: Improvement Components: Bean / Property Utils Environment: Operating System: other Platform: Other Reporter: Xavier Dury Fix For: LATER THAN 1.8.0 Hi, I know this has been asked already before but could there be a way to handle exceptions that occur during population? The populate() function could either return a map(property, exception), take that kind of map as argument or -even better- take a PopulateExceptionHandler as argument. The reason I would like to see this feature implemented is to allow struts to use this mechanism to convert parameters from the request to actionform's properties without *falling apart* when encountering one that is not well- formed. It would be nice too if we were not *forced* to use string-only properties for actionforms (which in fact is a way to circumvent this conversion problem). I would like my ActionForm or DynaActionForm declare strongly-typed properties (maybe custom classes), register proper Converters into ConvertUtils in the ActionServlet.initServlet() for example, and then maybe get back conversion errors from within my action (maybe the PopulateExceptionHandler could add some ActionErrors to the request). What do you think? I know this issue is tightly coupled to struts but well... ;-) Thanks a lot, Xavier -- 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: r555443 - /jakarta/commons/proper/beanutils/trunk/src/site/site.xml
Author: niallp Date: Wed Jul 11 17:14:40 2007 New Revision: 555443 URL: http://svn.apache.org/viewvc?view=revrev=555443 Log: Woops, forgot new site.xml Added: jakarta/commons/proper/beanutils/trunk/src/site/site.xml (with props) Added: jakarta/commons/proper/beanutils/trunk/src/site/site.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/beanutils/trunk/src/site/site.xml?view=autorev=555443 == --- jakarta/commons/proper/beanutils/trunk/src/site/site.xml (added) +++ jakarta/commons/proper/beanutils/trunk/src/site/site.xml Wed Jul 11 17:14:40 2007 @@ -0,0 +1,60 @@ +?xml version=1.0 encoding=ISO-8859-1? +!-- + Licensed to the Apache Software Foundation (ASF) under one or more + contributor license agreements. See the NOTICE file distributed with + this work for additional information regarding copyright ownership. + The ASF licenses this file to You under the Apache License, Version 2.0 + (the License); you may not use this file except in compliance with + the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an AS IS BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. +-- +project name=BeanUtils +bannerRight +nameCommons BeanUtils/name +src/images/logo.png/src +href/index.html/href +/bannerRight + +body +menu name=BeanUtils +item name=Overview href=/index.html/ +item name=Download href=http://jakarta.apache.org/site/downloads/downloads_commons-beanutils.cgi/ +item name=Dependencies href=/dependencies.html/ +item name=Mailing Listshref=/mail-lists.html/ +item name=Issue Tracking href=/issue-tracking.html/ +item name=Source Repositoryhref=/source-repository.html/ +item name=License href=/license.html/ +/menu + +menu name=Documentation +item name=Building href=/building.html/ +!-- item name=History href=/changes-report.html/ -- +item name=Wiki href=http://wiki.apache.org/jakarta-commons/BeanUtils/ +item name=Latest +item name=User Guide href=/apidocs/org/apache/commons/beanutils/package-summary.html#package_description/ +item name=API href=/apidocs/index.html/ +item name=Bean Collections href=/bean-collections/index.html/ +/item +item name=1.7.0 Release +item name=User Guide href=http://jakarta.apache.org/commons/beanutils/commons-beanutils-1.7.0/docs/api/org/apache/commons/beanutils/package-summary.html#package_description/ +item name=Core API href=http://jakarta.apache.org/commons/beanutils/commons-beanutils-1.7.0/docs/api/ +item name=Bean Collections href=http://jakarta.apache.org/commons/beanutils/commons-beanutils-1.7.0/docs/bean-collections/ +item name=Release Notes href=http://jakarta.apache.org/commons/beanutils/commons-beanutils-1.7.0/RELEASE-NOTES.txt/ +/item +item name=1.6.1 Release +item name=User Guide href=http://jakarta.apache.org/commons/beanutils/commons-beanutils-1.6.1/docs/api/org/apache/commons/beanutils/package-summary.html#package_description/ +item name=API href=http://jakarta.apache.org/commons/beanutils/commons-beanutils-1.6.1/docs/api// +item name=Release Notes href=http://jakarta.apache.org/commons/beanutils/commons-beanutils-1.6.1/RELEASE-NOTES.txt/ +/item +/menu + +/body + +/project Propchange: jakarta/commons/proper/beanutils/trunk/src/site/site.xml -- svn:eol-style = native Propchange: jakarta/commons/proper/beanutils/trunk/src/site/site.xml -- svn:keywords = Date Author Id Revision HeadURL - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TRANSACTION-15) Lightweight transaction leaks on exception from FileResourceManager.getResource
[ https://issues.apache.org/jira/browse/TRANSACTION-15?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511915 ] Antranig Basman commented on TRANSACTION-15: Thanks for your patch, which looks good for the earlier reported issue (in the May 2006 thread). However the supplied patch here and report are for a different issue, an exception safety issue in FileResourceManager - please could you review the patch - cheers :) Lightweight transaction leaks on exception from FileResourceManager.getResource --- Key: TRANSACTION-15 URL: https://issues.apache.org/jira/browse/TRANSACTION-15 Project: Commons Transaction Issue Type: Bug Affects Versions: 1.1, 1.2 Environment: Current trunk of rev 542554 Reporter: Antranig Basman Assignee: Oliver Zeigermann Attachments: patch.txt, transaction-lightweight-fix.txt FileResourceManager getResource(String) method will leak in the case an exception occurs during execution, in the most obvious case where the resource does not exist. This is because the method does not do proper cleanup of the lightweight transaction (which it allocated itself). Lightweight transactions in general are pretty sketchy in commons-transaction which I think is a fact that should be advertised a bit more widely - I was a little disappointed to see that the 1.2 release went ahead last month without any more attention to the issues that I raised last May - the thread begins 22nd May 2006 at http://mail-archives.apache.org/mod_mbox/jakarta-commons-user/200605.mbox/[EMAIL PROTECTED] (title: Memory leaks in GenericLockManager, FileResourceManager) The resolution to the leak I posted there was demonstrated not completely sound, but I think in the absence of any other approach it would be better than nothing - better that a heavyweight transaction immediately retried with the same ID will very rarely fail than that every lightweight transaction will leak :P In any case, this issue is more serious in that it is not just a leak, but will permanently lock a part of the resource tree for the lifetime of the ResourceManager. I have attached diffs for a patch and a test case for this issue below. -- 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]
[Jakarta-commons Wiki] Update of Collections/GenericCollections/Contributors by StephenKestle
Dear Wiki user, You have subscribed to a wiki page or wiki category on Jakarta-commons Wiki for change notification. The following page has been changed by StephenKestle: http://wiki.apache.org/jakarta-commons/Collections/GenericCollections/Contributors -- === Stephen Kestle === - My plans still stand, however I will be doing intensive house renovations until May, so may not get much done. I intend to finish [http://issues.apache.org/jira/browse/COLLECTIONS-247 COLLECTIONS-247 (Step 2)] soon though. + Well, house renovations finally finished 2 weeks ago. But we're having a baby within the next week, so things are still on hold somewhat. I should be able to put some time in before August. Also, this may become part of my day job around then as well. Plans - 1. Get build working and instructions on wiki + 1. Get build working and instructions on wiki ( [http://issues.apache.org/jira/browse/COLLECTIONS-247 COLLECTIONS-247]) 1. Update build to include [http://www.easymock.org/ EasyMock] and [http://www.junit.org/ JUnit4] 1. Update tests for !CollectionUtils 1. Expand !CollectionUtils test to cover the generic bounds - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-140) LocaleBeanUtils setProperty does not work on nested property
[ https://issues.apache.org/jira/browse/BEANUTILS-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-140: -- Assignee: Niall Pemberton Affects Version/s: 1.7.0 Summary: LocaleBeanUtils setProperty does not work on nested property (was: [beanutils] LocaleBeanUtils setProperty does not work on nested property) LocaleBeanUtils setProperty does not work on nested property Key: BEANUTILS-140 URL: https://issues.apache.org/jira/browse/BEANUTILS-140 Project: Commons BeanUtils Issue Type: Bug Components: Locale BeanUtils / Converters Affects Versions: 1.7.0 Environment: Operating System: All Platform: All Reporter: Marco La Porta Assignee: Niall Pemberton Fix For: 1.8.0 LocaleBeanUtils setProperty does not work on nested property. I think the problem is in the method definePropertyType(Object target, String name, String propName). When property is a nested property (prop1.propnested) target is the result of a call of the prop1 getter on the oroginal bean, name is the property name complete (prop1.propnested) and propName is the property name in target object (propnested). At line 601 the property descriptor is defined as descriptor = PropertyUtils.getPropertyDescriptor(target, name); and in case of nested propery it is never found (null) I think the correct line 601 is descriptor = PropertyUtils.getPropertyDescriptor(target, propName); -- 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: r555476 - /jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/locale/LocaleBeanUtilsTestCase.java
Author: niallp
Date: Wed Jul 11 20:08:37 2007
New Revision: 555476
URL: http://svn.apache.org/viewvc?view=revrev=555476
Log:
Add test for BEANUTILS-140 - LocaleBeanUtils setProperty does not work on
nested property - reposted by Marco La Porta
Added:
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/locale/LocaleBeanUtilsTestCase.java
(with props)
Added:
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/locale/LocaleBeanUtilsTestCase.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/locale/LocaleBeanUtilsTestCase.java?view=autorev=555476
==
---
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/locale/LocaleBeanUtilsTestCase.java
(added)
+++
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/locale/LocaleBeanUtilsTestCase.java
Wed Jul 11 20:08:37 2007
@@ -0,0 +1,106 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the License); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.beanutils.locale;
+
+import junit.framework.TestCase;
+import junit.framework.Test;
+import junit.framework.TestSuite;
+
+import org.apache.commons.beanutils.TestBean;
+import org.apache.commons.logging.Log;
+import org.apache.commons.logging.LogFactory;
+
+/**
+ * Test Case for [EMAIL PROTECTED] LocaleBeanUtils}.
+ *
+ * @version $Revision$ $Date$
+ */
+public class LocaleBeanUtilsTestCase extends TestCase {
+
+private static Log log = LogFactory.getLog(LocaleBeanUtilsTestCase.class);
+
+/**
+ * Construct a new instance of this test case.
+ *
+ * @param name Name of the test case
+ */
+public LocaleBeanUtilsTestCase(String name) {
+super(name);
+}
+
+
+// -- Overall Test Methods
+
+
+/**
+ * Set up instance variables required by this test case.
+ */
+public void setUp() {
+}
+
+
+/**
+ * Return the tests included in this test suite.
+ * @return Test Suite
+ */
+public static Test suite() {
+return (new TestSuite(LocaleBeanUtilsTestCase.class));
+}
+
+
+/**
+ * Tear down instance variables required by this test case.
+ */
+public void tearDown() {
+}
+
+
+// Individual Test Methods
+
+/**
+ * Test setting a nested simple property
+ */
+public void testSetNestedPropertySimple() {
+TestBean bean = new TestBean();
+bean.getNested().setIntProperty(5);
+assertEquals(Initial value 5, 5, bean.getNested().getIntProperty());
+try {
+LocaleBeanUtils.setProperty(bean, nested.intProperty, 123,
null);
+} catch (Throwable t) {
+log.error(t);
+fail(Threw + t);
+}
+assertEquals(Check Set Value, 123,
bean.getNested().getIntProperty());
+}
+
+/**
+ * Test setting a nested indexed property
+ */
+public void testSetNestedPropertyIndexed() {
+TestBean bean = new TestBean();
+bean.getNested().setIntIndexed(1, 51);
+assertEquals(Initial value[1] 51, 51,
bean.getNested().getIntIndexed(1));
+try {
+LocaleBeanUtils.setProperty(bean, nested.intIndexed[1], 123,
null);
+} catch (Throwable t) {
+log.error(t);
+fail(Threw + t);
+}
+assertEquals(Check Set Value, 123,
bean.getNested().getIntIndexed(1));
+}
+}
+
Propchange:
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/locale/LocaleBeanUtilsTestCase.java
--
svn:eol-style = native
Propchange:
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/locale/LocaleBeanUtilsTestCase.java
--
svn:keywords = Date Author Id Revision HeadURL
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[jira] Resolved: (BEANUTILS-140) LocaleBeanUtils setProperty does not work on nested property
[ https://issues.apache.org/jira/browse/BEANUTILS-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved BEANUTILS-140. --- Resolution: Invalid I added a test case for this but can't reproduce this in either the current trunk or BeanUtils 1.7.0 LocaleBeanUtils setProperty does not work on nested property Key: BEANUTILS-140 URL: https://issues.apache.org/jira/browse/BEANUTILS-140 Project: Commons BeanUtils Issue Type: Bug Components: Locale BeanUtils / Converters Affects Versions: 1.7.0 Environment: Operating System: All Platform: All Reporter: Marco La Porta Assignee: Niall Pemberton Fix For: 1.8.0 LocaleBeanUtils setProperty does not work on nested property. I think the problem is in the method definePropertyType(Object target, String name, String propName). When property is a nested property (prop1.propnested) target is the result of a call of the prop1 getter on the oroginal bean, name is the property name complete (prop1.propnested) and propName is the property name in target object (propnested). At line 601 the property descriptor is defined as descriptor = PropertyUtils.getPropertyDescriptor(target, name); and in case of nested propery it is never found (null) I think the correct line 601 is descriptor = PropertyUtils.getPropertyDescriptor(target, propName); -- 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: (BEANUTILS-204) [beanutils] LocaleBeanUtils.copyProperties() does not use Locale aware converions
[ https://issues.apache.org/jira/browse/BEANUTILS-204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-204: -- Fix Version/s: (was: 1.8.0) LATER THAN 1.8.0 Needs someone to provide a copyProperties() implementation for LocaleBeanUtilsBean (currently just inheriting from BeanUtilsBean) - punting to post 1.8.0 since no one has stepped up to do this. [beanutils] LocaleBeanUtils.copyProperties() does not use Locale aware converions - Key: BEANUTILS-204 URL: https://issues.apache.org/jira/browse/BEANUTILS-204 Project: Commons BeanUtils Issue Type: Improvement Components: Locale BeanUtils / Converters Affects Versions: 1.5 Environment: Operating System: other Platform: Other Reporter: Robert Burrell Donkin Priority: Minor Fix For: LATER THAN 1.8.0 for more details see http://marc.theaimsgroup.com/?l=jakarta-commons-userm=104239393332710w=2 this functionality would be a little tricky to add and can wait until after the 1.6 release. -- 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: new VFS provider
You might try using the webdav provider as a guide to creating your own provider. The unit tests will help you sort out the implementation characteristics. Hope this helps, Mark On 7/11/07, Brian Dilley [EMAIL PROTECTED] wrote: I'm interested in implementing a JDBC based provider that also maintains a local (Disk FS based) cache of the files as well. Is there any documentation on implementing a new provider for VFS? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r555489 - in /jakarta/commons/proper/beanutils/trunk/src: java/org/apache/commons/beanutils/locale/converters/FloatLocaleConverter.java test/org/apache/commons/beanutils/locale/converters/
Author: niallp
Date: Wed Jul 11 21:53:26 2007
New Revision: 555489
URL: http://svn.apache.org/viewvc?view=revrev=555489
Log:
BEANUTILS-44 FloatLocaleConverter cannot parse negative values - reported by
Paul Jenkins
Modified:
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/locale/converters/FloatLocaleConverter.java
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/locale/converters/FloatLocaleConverterTestCase.java
Modified:
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/locale/converters/FloatLocaleConverter.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/locale/converters/FloatLocaleConverter.java?view=diffrev=555489r1=555488r2=555489
==
---
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/locale/converters/FloatLocaleConverter.java
(original)
+++
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/locale/converters/FloatLocaleConverter.java
Wed Jul 11 21:53:26 2007
@@ -214,8 +214,10 @@
*/
protected Object parse(Object value, String pattern) throws ParseException {
final Number parsed = (Number) super.parse(value, pattern);
- if( Math.abs(parsed.doubleValue() - parsed.floatValue())
parsed.floatValue() * 0.1 ) {
- throw new ConversionException(Suplied number is not of type Float:
+parsed.longValue());
+ double doubleValue = parsed.doubleValue();
+ double posDouble = (doubleValue = (double)0) ? doubleValue :
(doubleValue * (double)-1);
+ if (posDouble Float.MIN_VALUE || posDouble Float.MAX_VALUE) {
+ throw new ConversionException(Suplied number is not of type Float:
+parsed);
}
return new Float(parsed.floatValue()); // unlike superclass it returns
Float type
}
Modified:
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/locale/converters/FloatLocaleConverterTestCase.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/locale/converters/FloatLocaleConverterTestCase.java?view=diffrev=555489r1=555488r2=555489
==
---
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/locale/converters/FloatLocaleConverterTestCase.java
(original)
+++
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/locale/converters/FloatLocaleConverterTestCase.java
Wed Jul 11 21:53:26 2007
@@ -17,6 +17,8 @@
package org.apache.commons.beanutils.locale.converters;
+import java.text.DecimalFormat;
+import org.apache.commons.beanutils.ConversionException;
/**
* Test Case for the FloatLocaleConverter class.
@@ -256,6 +258,49 @@
convertInvalid(converter, defaultValue);
convertNull(converter, defaultValue);
+}
+
+/**
+ * Test Float limits
+ */
+public void testFloatLimits() {
+
+converter = new FloatLocaleConverter(defaultLocale,
defaultDecimalPattern);
+DecimalFormat fmt = new
DecimalFormat(#.#);
+
+assertEquals(new Float(-0.12), converter.convert(-0.12));
+assertEquals(Positive Float.MAX_VALUE, new Float(Float.MAX_VALUE),
converter.convert(fmt.format(Float.MAX_VALUE)));
+assertEquals(Positive Float.MIN_VALUE, new Float(Float.MIN_VALUE),
converter.convert(fmt.format(Float.MIN_VALUE)));
+
+assertEquals(Negative Float.MAX_VALUE, new Float(Float.MAX_VALUE *
-1), converter.convert(fmt.format(Float.MAX_VALUE * -1)));
+assertEquals(Negative Float.MIN_VALUE, new Float(Float.MIN_VALUE *
-1), converter.convert(fmt.format(Float.MIN_VALUE * -1)));
+
+
+try {
+converter.convert(fmt.format((double)Float.MAX_VALUE *
(double)10));
+fail(Positive Too Large should throw ConversionException);
+} catch (ConversionException e) {
+// expected result
+}
+try {
+converter.convert(fmt.format((double)Float.MAX_VALUE *
(double)-10));
+fail(Negative Too Large should throw ConversionException);
+} catch (ConversionException e) {
+// expected result
+}
+
+try {
+converter.convert(fmt.format((double)Float.MIN_VALUE /
(double)10));
+fail(Positive Too Small should throw ConversionException);
+} catch (ConversionException e) {
+// expected result
+}
+try {
+converter.convert(fmt.format((double)Float.MIN_VALUE /
(double)-10));
+fail(Negative Too Small should throw ConversionException);
+} catch (ConversionException e) {
+// expected result
+}
}
[jira] Updated: (BEANUTILS-44) FloatLocaleConverter cannot parse negative values
[
https://issues.apache.org/jira/browse/BEANUTILS-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton updated BEANUTILS-44:
-
Affects Version/s: 1.7.0
Summary: FloatLocaleConverter cannot parse negative values (was:
[beanutils] FloatLocaleConverter cannot parse negative values)
FloatLocaleConverter cannot parse negative values
-
Key: BEANUTILS-44
URL: https://issues.apache.org/jira/browse/BEANUTILS-44
Project: Commons BeanUtils
Issue Type: Bug
Components: Locale BeanUtils / Converters
Affects Versions: 1.7.0
Environment: Operating System: All
Platform: All
Reporter: Paul Jenkins
Fix For: 1.8.0
Problem found in Build 1.7
LocaleBeanUtils.setProperty(bean, name, value);
Does not handle negative values. When processing negative values the
FloatLocaleConverter.parse(value, pattern) throws a ConversionException
because
of the following if test: -
if(Math.abs(parsed.doubleValue() - parsed.floatValue())
parsed.floatValue() * 0.1) {
throw new ConversionException(...);
}
This test will always fail for a valid negative value because the
multiplication by 0.1 will result in a negative value which will be less
then the abs subtraction.
A solution to this problem would be to check Math.abs(parsed.floatValue() *
0.1)
We also suffer from the previously reported problem of the locale converters
not supporting boolean to get round this problem we have to determine the
property type and call either LocaleBeanUtils.setProperty() or
BeanUtils.setProperty() this would be made easier if the: -
protected Descriptor calculate(Object bean, String name)
method was made public.
--
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] Resolved: (BEANUTILS-44) FloatLocaleConverter cannot parse negative values
[
https://issues.apache.org/jira/browse/BEANUTILS-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton resolved BEANUTILS-44.
--
Resolution: Fixed
Assignee: Niall Pemberton
FloatLocaleConverter cannot parse negative values
-
Key: BEANUTILS-44
URL: https://issues.apache.org/jira/browse/BEANUTILS-44
Project: Commons BeanUtils
Issue Type: Bug
Components: Locale BeanUtils / Converters
Affects Versions: 1.7.0
Environment: Operating System: All
Platform: All
Reporter: Paul Jenkins
Assignee: Niall Pemberton
Fix For: 1.8.0
Problem found in Build 1.7
LocaleBeanUtils.setProperty(bean, name, value);
Does not handle negative values. When processing negative values the
FloatLocaleConverter.parse(value, pattern) throws a ConversionException
because
of the following if test: -
if(Math.abs(parsed.doubleValue() - parsed.floatValue())
parsed.floatValue() * 0.1) {
throw new ConversionException(...);
}
This test will always fail for a valid negative value because the
multiplication by 0.1 will result in a negative value which will be less
then the abs subtraction.
A solution to this problem would be to check Math.abs(parsed.floatValue() *
0.1)
We also suffer from the previously reported problem of the locale converters
not supporting boolean to get round this problem we have to determine the
property type and call either LocaleBeanUtils.setProperty() or
BeanUtils.setProperty() this would be made easier if the: -
protected Descriptor calculate(Object bean, String name)
method was made public.
--
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-284) ability to read OS environment variables
[
https://issues.apache.org/jira/browse/CONFIGURATION-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vasily Ivanov updated CONFIGURATION-284:
Attachment: EnvironmentConfiguration.java
I have create simple Configuration to read environment variables. Please see
file attached.
Also, I have tried to use
PropertiesConfiguration.PropertiesReader#parseProperty(String line) magic, but
it returns corrupted Windows paths by unescapeing variables values when it is
not necessary. I didn't find a way to prevent it doing that. However, here is
the code for you convenience if you want to play around:
private static Properties readEnvVariables(final InputStream in) throws
IOException
{
Properties props = new Properties();
PropertiesConfiguration.PropertiesReader reader =
new PropertiesConfiguration.PropertiesReader(new InputStreamReader(in));
while (reader.nextProperty()) {
props.setProperty(reader.getPropertyName(), reader.getPropertyValue());
}
return props;
}
Note: I haven't tested it in UNIX, but it should work just fine.
ability to read OS environment variables
Key: CONFIGURATION-284
URL: https://issues.apache.org/jira/browse/CONFIGURATION-284
Project: Commons Configuration
Issue Type: New Feature
Components: Interpolation
Reporter: Aksel Schmidt
Priority: Minor
Attachments: EnvironmentConfiguration.java
suggestion:
interpolation with system environment, i.e.
${sys:user.name} reads from systemproperties (as of today)
${sysenv:TEMP} reads from OS environment
these can be parsed from a supported set of OS's - windows read from a set in
a cmd /c, unix/linux from an env etc. (just once on demand)
--
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: (BEANUTILS-18) [beanutils] PropertyUtils.isReadable() and PropertyUtils.getProperty() not consistent
[ https://issues.apache.org/jira/browse/BEANUTILS-18?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511973 ] Henri Yandell commented on BEANUTILS-18: I'm +1 to the view that this is a bug and not a backwards compatibility issue. isReadable should return false if the method is not readable. [beanutils] PropertyUtils.isReadable() and PropertyUtils.getProperty() not consistent - Key: BEANUTILS-18 URL: https://issues.apache.org/jira/browse/BEANUTILS-18 Project: Commons BeanUtils Issue Type: Bug Components: Bean / Property Utils Environment: Operating System: Windows 2000 Platform: PC Reporter: Maarten Coene Fix For: 1.8.0 Attachments: BEANUTILS-18-PropertyUtilsBean.patch, patch-PropertyUtilsBean.txt, patch-PropertyUtilsTestCase.txt, PropertyUtilsTest.java Hi, When the object passed to PropertyUtils is a non-public class, the PropertyUtils.isReadable() method returns true for an existing property while the PropertyUtils.getProperty() method for the same property throws a NoSuchMethodException. I'll attach a junit test that illustrates the problem. regards, Maarten -- 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]
