Re: [LANG] 3.0 status
On Sat, Dec 12, 2009 at 5:18 AM, sebb seb...@gmail.com wrote: On 12/12/2009, Henri Yandell flame...@gmail.com wrote: Updating status again. * 103 resolved issues out of 161. From Sep 6 we resolved 38 issues and had 30 new ones. * 78 contributors involved in the resolved issues, 80 patches and 511 comments. We just hit 66% resolved! And the face on the release portlet is smiley again; I don't know how anyone develops without emoticons to tell them when they need to code :) * I believe we now have 3 issues that would benefit from JDK 1.6. Sun have end of lifed Java 1.5, though presumably there are other vendors who haven't. Personally I still lean towards becoming 1.6 dependent. Which are these? Could LANG still be built to be 1.5 compatible, apart from the code that uses the 1.6 features? One was the stripAccents method I just added. It's 1.6 dependent, but uses reflection. Another was removing code - in 1.6 we get to remove another chunk of code :) I forget the other one. Seems to me that going from a minimum of Java 1.2 for 2.x to Java 1.6 for lang 3.x is a huge leap. Sun don't support it. Mac no longer ships with it. Equally, I do accept that 1.6 doesn't have as much value as 1.5 does in terms of new APIs for us to write code around. * Still lots to work on. Here's a short list of very approachable issues (be they simple or tricky): Noting various issues pending Paul Benedict :) Do you have any thoughts on LANG-556? Also, you've reported 7 issues and have 2 assigned to you. Any plans on those? Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [LANG] 3.0 status
On Mon, Dec 14, 2009 at 12:03 AM, Henri Yandell flame...@gmail.com wrote: On Sat, Dec 12, 2009 at 5:18 AM, sebb seb...@gmail.com wrote: On 12/12/2009, Henri Yandell flame...@gmail.com wrote: Updating status again. * 103 resolved issues out of 161. From Sep 6 we resolved 38 issues and had 30 new ones. * 78 contributors involved in the resolved issues, 80 patches and 511 comments. We just hit 66% resolved! And the face on the release portlet is smiley again; I don't know how anyone develops without emoticons to tell them when they need to code :) * I believe we now have 3 issues that would benefit from JDK 1.6. Sun have end of lifed Java 1.5, though presumably there are other vendors who haven't. Personally I still lean towards becoming 1.6 dependent. Which are these? Could LANG still be built to be 1.5 compatible, apart from the code that uses the 1.6 features? One was the stripAccents method I just added. It's 1.6 dependent, but uses reflection. Another was removing code - in 1.6 we get to remove another chunk of code :) I forget the other one. Seems to me that going from a minimum of Java 1.2 for 2.x to Java 1.6 for lang 3.x is a huge leap. Sun don't support it. Mac no longer ships with it. Equally, I do accept that 1.6 doesn't have as much value as 1.5 does in terms of new APIs for us to write code around. * Still lots to work on. Here's a short list of very approachable issues (be they simple or tricky): Noting various issues pending Paul Benedict :) Do you have any thoughts on LANG-556? Also, you've reported 7 issues and have 2 assigned to you. Any plans on those? Noting tired Brit who thought he was replying to Paul not Sebb. Ack. Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r890409 - in /commons/proper/jexl/trunk/src: main/java/org/apache/commons/jexl2/ main/java/org/apache/commons/jexl2/internal/introspection/ test/java/org/apache/commons/jexl2/
On 14/12/2009, hen...@apache.org hen...@apache.org wrote:
Author: henrib
Date: Mon Dec 14 17:38:45 2009
New Revision: 890409
URL: http://svn.apache.org/viewvc?rev=890409view=rev
Log:
fixed JEXL-94; modified test accordingly. Also fixed a bug in
MethodKey#isApplicable that surfaced through test.
...
Modified:
commons/proper/jexl/trunk/src/test/java/org/apache/commons/jexl2/MethodTest.java
URL:
http://svn.apache.org/viewvc/commons/proper/jexl/trunk/src/test/java/org/apache/commons/jexl2/MethodTest.java?rev=890409r1=890408r2=890409view=diff
==
---
commons/proper/jexl/trunk/src/test/java/org/apache/commons/jexl2/MethodTest.java
(original)
+++ commons/proper/jexl/trunk/src/test/java/org/apache/commons/jexl2
...
+/**
+ * Runs a test.
+ * @param args where args[0] is the test class name and args[1] the
test class method
Javadoc disagrees with code.
However, I'm not sure it's useful to have main() methods in test cases
as Maven and Eclipse allow individual cases to be run directly anyway.
+ * @throws Exception
+ */
+public static void main(String[] args) throws Exception {
+runTest(MethodTest, testNamespaceCall);
+}
}
\ No newline at end of file
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r890409 - in /commons/proper/jexl/trunk/src: main/java/org/apache/commons/jexl2/ main/java/org/apache/commons/jexl2/internal/introspection/ test/java/org/apache/commons/jexl2/
On 14/12/2009, hen...@apache.org hen...@apache.org wrote:
Author: henrib
Date: Mon Dec 14 17:38:45 2009
New Revision: 890409
URL: http://svn.apache.org/viewvc?rev=890409view=rev
Log:
fixed JEXL-94; modified test accordingly. Also fixed a bug in
MethodKey#isApplicable that surfaced through test.
Modified:
commons/proper/jexl/trunk/src/main/java/org/apache/commons/jexl2/Interpreter.java
commons/proper/jexl/trunk/src/main/java/org/apache/commons/jexl2/JexlEngine.java
commons/proper/jexl/trunk/src/main/java/org/apache/commons/jexl2/internal/introspection/MethodKey.java
commons/proper/jexl/trunk/src/test/java/org/apache/commons/jexl2/MethodTest.java
Modified:
commons/proper/jexl/trunk/src/main/java/org/apache/commons/jexl2/Interpreter.java
URL:
http://svn.apache.org/viewvc/commons/proper/jexl/trunk/src/main/java/org/apache/commons/jexl2/Interpreter.java?rev=890409r1=890408r2=890409view=diff
==
---
commons/proper/jexl/trunk/src/main/java/org/apache/commons/jexl2/Interpreter.java
(original)
+++
commons/proper/jexl/trunk/src/main/java/org/apache/commons/jexl2/Interpreter.java
Mon Dec 14 17:38:45 2009
@@ -97,6 +97,8 @@
protected final JexlArithmetic arithmetic;
/** The map of registered functions. */
protected final MapString, Object functions;
+/** The map of registered functions. */
+protected MapString, Object functors;
Could/should be private.
Indeed so should all the other instance variables...
/** The context to store/retrieve variables. */
protected final JexlContext context;
/** Strict interpreter flag. */
@@ -124,6 +126,7 @@
this.silent = jexl.silent;
this.cache = jexl.cache != null;
this.context = aContext;
+this.functors = null;
Why not allocate an empty HashMap here?
It would save a lot of null checking later, and the variable could
then be final.
}
/**
@@ -231,6 +234,46 @@
return null;
}
+/**
+ * Resolves a namespace, eventually allocating an instance using
context as constructor argument.
+ * The lifetime of such instances span the current expression or script
evaluation.
+ *
+ * @param prefix the prefix name (may be null for global namespace)
+ * @param node the AST node
+ * @return the namespace instance
+ */
+protected Object resolveNamespace(String prefix, JexlNode node) {
+Object namespace;
+// check whether this namespace is a functor
+if (functors != null) {
+namespace = functors.get(prefix);
+if (namespace != null) {
+return namespace;
+}
+}
+namespace = functions.get(prefix);
+if (namespace == null) {
+throw new JexlException(node, no such function namespace +
prefix);
+}
+// allow namespace to be instantiated as functor with context
+if (namespace instanceof Class?) {
+Object[] args = new Object[]{context};
+Constructor? ctor = uberspect.getConstructor(namespace,args,
node);
+if (ctor != null) {
+try {
+namespace = ctor.newInstance(args);
+if (functors == null) {
+functors = new HashMapString, Object();
+}
+functors.put(prefix, namespace);
+} catch (Exception xinst) {
+throw new JexlException(node, unable to instantiate
namespace + prefix, xinst);
+}
+}
+}
+return namespace;
+}
+
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r890409 - in /commons/proper/jexl/trunk/src: main/java/org/apache/commons/jexl2/ main/java/org/apache/commons/jexl2/internal/introspection/ test/java/org/apache/commons/jexl2/
All members in JexlEngine are protected so JexlEngine can be derived easily. As for the functors map, there is no reason to allocate that map before hand if the expression does not use any; there will likely be far more exprs evaluated without namespaces than the opposite. There are only 2 occurrences of null checking for functors and these are located in the same function. I dont feel like I'm bending proper coding rules here. Btw, any news on the bsf3 artefact in the repository ? sebb-2-2 wrote: ... protected final JexlArithmetic arithmetic; /** The map of registered functions. */ protected final MapString, Object functions; +/** The map of registered functions. */ +protected MapString, Object functors; Could/should be private. Indeed so should all the other instance variables... ... +this.functors = null; Why not allocate an empty HashMap here? It would save a lot of null checking later, and the variable could then be final. -- View this message in context: http://n4.nabble.com/Re-svn-commit-r890409-in-commons-proper-jexl-trunk-src-main-java-org-apache-commons-jexl2-main-java--tp963766p963796.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r890409 - in /commons/proper/jexl/trunk/src: main/java/org/apache/commons/jexl2/ main/java/org/apache/commons/jexl2/internal/introspection/ test/java/org/apache/commons/jexl2/
Removed it, was leftover from debug in NB.
Thanks for pointing it out.
sebb-2-2 wrote:
However, I'm not sure it's useful to have main() methods in test cases
as Maven and Eclipse allow individual cases to be run directly anyway.
...
+public static void main(String[] args) throws Exception {
+runTest(MethodTest, testNamespaceCall);
+}
}
...
--
View this message in context:
http://n4.nabble.com/Re-svn-commit-r890409-in-commons-proper-jexl-trunk-src-main-java-org-apache-commons-jexl2-main-java--tp963766p963800.html
Sent from the Commons - Dev mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [dbcp] 1.3/1.4 RC1 available for review
Hi Phil, Phil Steitz wrote: [snip] 1.4 (JDBC 4) version: http://people.apache.org/~psteitz/dbcp-1.4-rc1 http://people.apache.org/~psteitz/dbcp-1.4-rc1/site http://people.apache.org/~psteitz/dbcp-1.4-rc1/maven http://svn.apache.org/repos/asf/commons/proper/dbcp/tags/DBCP_1_4_RC1/ Builds from source and runs tests with IcedTea6 1.6.2, Sun JDK 1.6 and Sun JDK 1.7.0.0.alpha69 (add to README.txt ?!?). However it fails with IBM 1.6.0.6: == % --- Test set: org.apache.commons.dbcp.managed.TestBasicManagedDataSource --- Tests run: 46, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 3.398 sec FAILURE! testReallyClose(org.apache.commons.dbcp.managed.TestBasicManagedDataSource) Time elapsed: 0.066 sec FAILURE! junit.framework.AssertionFailedError: Expecting SQLException - XAResources orphaned at junit.framework.Assert.fail(Assert.java:47) at org.apache.commons.dbcp.managed.TestBasicManagedDataSource.testReallyClose(TestBasicManagedDataSource.java:72) I could use some help debugging this one. I do not have the JDK to test with and the failure makes no sense to me. Does it happen every time? It seems it was caused by a difference in the WeakReference implementation. The DelegactingConnection returned the same hashCode than the inner connection. However, both instances were kept in the registry in xaReference (a WeakMap). After using a distinguishable hashCode, the test succeeds also with IBM JDK. Additionally I dropped the JDK 1.4 deps from the POM. I'll look into DBCP 1.3 ASAP - it got too late now ;-) - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[continuum] BUILD FAILURE: Commons - Commons DBCP -
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=258186projectId=22 Build statistics: State: Failed Previous State: Ok Started at: Mon 14 Dec 2009 15:46:42 -0800 Finished at: Mon 14 Dec 2009 15:48:51 -0800 Total time: 2m 9s Build Trigger: Schedule Build Number: 116 Exit code: 1 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java Home version : java version 1.6.0_06 Java(TM) SE Runtime Environment (build 1.6.0_06-b02) Java HotSpot(TM) Client VM (build 10.0-b22, mixed mode, sharing) Builder version : Maven version: 2.0.9 Java version: 1.6.0_06 OS name: linux version: 2.6.24-23-server arch: i386 Family: unix SCM Changes: Changed: niallp @ Mon 7 Dec 2009 17:57:50 -0800 Comment: Remove commons.binary.suffix from poms so it picks up the default -bin value from commons-parent and correct links on download page Files changed: /commons/proper/dbcp/trunk/pom-1.3.xml ( 888223 ) /commons/proper/dbcp/trunk/pom.xml ( 888223 ) /commons/proper/dbcp/trunk/xdocs/download_dbcp.xml ( 888223 ) Dependencies Changes: No dependencies changed Build Definition: POM filename: pom.xml Goals: clean deploy Arguments: --batch-mode -DaltDeploymentRepository=vmbuild.repo::default::file://localhost/home/continuum/data/commons -Pci Build Fresh: false Always Build: false Default Build Definition: true Schedule: COMMONS_SCHEDULE Profile Name: JDK 6 Description: Test Summary: Tests: 443 Failures: 0 Errors: 33 Success Rate: 92 Total time: 54.804005 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
