[Velocity Wiki] Update of LoggingLevel by NathanBubna
Dear Wiki user, You have subscribed to a wiki page or wiki category on Velocity Wiki for change notification. The following page has been changed by NathanBubna: http://wiki.apache.org/velocity/LoggingLevel The comment on the change is: initial revision New page: This is the project guideline for when the various log levels are appropriate/useful in Velocity classes. The aim here is keep Velocity log messages from becoming annoying, from hurting runtime performance, and especially to keep them as useful as possible. == Base Rules == *If you are logging below ERROR level, then you should wrap the log call and creation of the relevant message in an if (log.is[Level]Enabled()) block. *Try to keep messages and informative and non-generalized as possible == When Each Level Is Appropriate == === TRACE === This is the level for things that may be useful to know when debugging Velocity itself. These are unlikely to be useful to anyone but those working to improve Velocity. === DEBUG === This level is appropriate for information that would be used during development (aka debugging) of an application using Velocity. This includes all configuration settings (whether defaults or not) at runtime initialization, engine state changes such as the addition of a new !Velocimacro, unhandled invalid references, resource loader activity, etc. This is not a level for things that would just be noise to a Velocity user. === INFO === This is the least useful level for a component library like Velocity. It is best limited to things of interest to a Velocity user/app during production, which is almost nothing. If you really want Velocity to make any production runtime info available, consider using something like JMX, not the logging API. === WARN === Again, not very useful for us. This is legitimate for when the Velocity user is doing something that is likely unwise but not a clear error. Don't given in to the temptation to use it when Velocity recovers from an minor error, when the user tries to do something forbidden by the configuration, or when there has been a misconfiguration, all of those things are errors. === ERROR === This is for when something goes wrong (whether Velocity recovers from it or not), when the user tries to do something not allowed by the configuration, and when there is a mis-configuration. It generally isn't be Velocity's job to clean up such messes, but work hard to to point out what went wrong and where as clearly as you can. === FATAL === Not to be used. Anything fatal to Velocity itself should just be logged as an error and passed up to the app or framework using Velocity. They can decide whether it's fatal to the app or not. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Velocity Wiki] Update of CodeStandards by NathanBubna
Dear Wiki user, You have subscribed to a wiki page or wiki category on Velocity Wiki for change notification. The following page has been changed by NathanBubna: http://wiki.apache.org/velocity/CodeStandards The comment on the change is: add link to log level conventions -- Below is a list of coding conventions that are specific to Velocity, everything else not specificially mentioned here should follow the official [http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html Sun Java Coding Conventions]. + + If your contribution will be making use of any of the logging facilities, please follow + the projects LoggingLevel conventions as well. 1. Brackets should begin and end on a new line. Examples: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: Log levels
Given that i seem to have at least a small consensus, i've added a relevant wiki page (please feel free to enhance and edit) and am moving forward with the code changes. If consensus changes, it should be quick to undo or adjust these things. On 9/24/07, Malcolm Edgar [EMAIL PROTECTED] wrote: Yes and excessive logging also hurts performance. regards Malcolm Edgar On 9/25/07, Will Glass-Husain [EMAIL PROTECTED] wrote: Nicely stated. Though perhaps I don't care quite as much about the INFO stuff. (I keep my libraries on WARN by default). We have to be humble. Velocity is often just a little library in a much bigger application. It always annoys me when I fire it up just to send an email and there are tons of messages. (admittedly, most open source libraries are worse). WILL On 9/24/07, Malcolm Edgar [EMAIL PROTECTED] wrote: +1 I agree completely with these guidelines. If a framework (Velocity) is doing its job correctly, it doesn't need to tell the world about it (INFO). regards Malcolm Edgar On 9/25/07, Nathan Bubna [EMAIL PROTECTED] wrote: hey folks, for various reasons, i've been running Velocity from the command line a lot more lately, and i'm starting to find myself annoyed by INFO log messages (yes, even after all my log message/level/facility tweaking of the last few years). so i've started thinking that it'd be handy to have an established guideline for when the various log levels are appropriate/useful in developing a component library such as Velocity. does anyone know of somewhere where people have already thought this through and documented their conclusions? alternately, we should create our own on the wiki. here's my current thoughts (which still feel quite malleable): TRACE: This is the level for things that may be useful to know when debugging *Velocity itself*. These are unlikely to be useful to anyone else. DEBUG: This level seems most appropriate for information that would be used during development (aka debugging) of an application *using Velocity*. This would include all configuration settings (whether defaults or not) on runtime initialization, engine state changes such as the addition of a new Velocimacro, unhandled invalid references, resource loader activity, etc. This is not a level for things that would just be noise to a Velocity user. INFO: I increasingly think this is the least useful level for a component library like Velocity. I think it is best limited to things of interest to a Velocity user/app during production, which is not really a component type of thing to do. If we really wanted Velocity to make any production runtime info available, it probably would be through something like JMX, not through the logging API. Everything i see logging at INFO level right now should probably drop to DEBUG. WARN: Again, not very useful for us. I see this as legitimate for when the Velocity user is doing something that is likely unwise but not a clear error. Scanning our codebase, i see only one place in ResourceManagerImpl:510 where WARN seems appropriate. Too often we use it when Velocity recovers from an minor error, when the user tries to do something forbidden by the configuration, or when there has been a misconfiguration, all of which should be errors. ERROR: This is for when something goes wrong (whether Velocity recovers from it or not), when the user tries to do something not allowed by the configuration, and when there is a mis-configuration. Since we're talking about errors, some of the ones we catch and recover problem should probably be changed to throw exceptions. Velocity is meant to be a component library. It shouldn't be our job to clean up others messes; it's just our job to point out what went wrong and where as clearly as we can. FATAL: Once again, probably not really meant for a component like Velocity. Anything fatal to Velocity itself should just be logged as an error and passed up to the app or framework using Velocity. They can decide whether it's fatal to the app or not. Refinements, thoughts, or objections before i start acting on some of this? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (VELOCITY-443) Velocity 1.4 does not support Iterable collections.
[ https://issues.apache.org/jira/browse/VELOCITY-443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Bubna reopened VELOCITY-443: --- Assignee: Nathan Bubna (was: Henning Schmiedehausen) I see no reason not to simply support any object with an iterator() method. Then we get Iterable support and more, without dependency on JDK 5 or requiring the user to use a different Uberspect. It would also be completely backwards compatible and not affect performance of any previously functional templates. Velocity 1.4 does not support Iterable collections. --- Key: VELOCITY-443 URL: https://issues.apache.org/jira/browse/VELOCITY-443 Project: Velocity Issue Type: Improvement Affects Versions: 1.4 Environment: Java 5 Reporter: Peter Lawrey Assignee: Nathan Bubna Priority: Minor Fix For: 1.6 In the new for loop in Java 5 e.g. for(Object obj: iterable) the collection iterated only needs to be of type Iterable However, In Velocity a foreach loop must be either a Collection or a Map but cannot be just an Iterable. Suggestion, support Iterable containers. -- 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: (VELOCITY-443) Velocity 1.4 does not support Iterable collections.
[ https://issues.apache.org/jira/browse/VELOCITY-443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Bubna resolved VELOCITY-443. --- Resolution: Fixed Fixed in revision 579331. Velocity 1.4 does not support Iterable collections. --- Key: VELOCITY-443 URL: https://issues.apache.org/jira/browse/VELOCITY-443 Project: Velocity Issue Type: Improvement Affects Versions: 1.4 Environment: Java 5 Reporter: Peter Lawrey Assignee: Nathan Bubna Priority: Minor Fix For: 1.6 In the new for loop in Java 5 e.g. for(Object obj: iterable) the collection iterated only needs to be of type Iterable However, In Velocity a foreach loop must be either a Collection or a Map but cannot be just an Iterable. Suggestion, support Iterable containers. -- 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: (VELOCITY-365) handle Lists arrays similarly
[ https://issues.apache.org/jira/browse/VELOCITY-365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Bubna resolved VELOCITY-365. --- Resolution: Duplicate Fix Version/s: 2.0 1.6 This is a duplicate of VELOCITY-533. handle Lists arrays similarly --- Key: VELOCITY-365 URL: https://issues.apache.org/jira/browse/VELOCITY-365 Project: Velocity Issue Type: Improvement Components: Engine Affects Versions: 1.6 Environment: Operating System: All Platform: All Reporter: Nathan Bubna Priority: Minor Fix For: 1.6, 2.0 ok, the motive of this feature request is that we shouldn't have to distinguish between an $array and a $list when writing templates. this is already handled to a degree in the #foreach() directive which transparently handles both arrays and Lists (among other things), and it seems logically consistent with the way VTL already hides the difference between primitives and their wrappers (int vs. Integer). so, in this same spirit, i propose that we should enable template authors to access items by index, determine the size of, and manipulate (to a point) Lists and arrays identically. here's an example that demonstrates how i think this should work: Access Item at Index 2: $list.get(2) ##works already $array.get(2) ##doesn't work right now Determine size: $list.size() ##works already $array.size() ##wish this would work you get the idea, right? basically, i would like to have all operations that make sense for an array supported (which i believe means most List methods except the add(), remove(), and clear() ones). IMHO, this would simplify things for users noticeably and eliminate the need for such things as an ArrayTool in the VelocityTools library. at this point, i'm not sure what the best approach for implementing this is. it may simply be the automatic, transparent wrapping of arrays inserted into the context with some sort of ArrayList wrapper class. or i suppose it could involve some crazy Uberspect trickery. now all we need is someone with the time to whip up a patch... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r579331 - in /velocity/engine/trunk/src: java/org/apache/velocity/util/introspection/UberspectImpl.java test/org/apache/velocity/test/ForeachTestCase.java
Wow, Nathan -- you are on a tear. Nice work.
WILL
On 9/25/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: nbubna
Date: Tue Sep 25 10:59:43 2007
New Revision: 579331
URL: http://svn.apache.org/viewvc?rev=579331view=rev
Log:
support any object with an iterator() method in #foreach (VELOCITY-443)
Modified:
velocity/engine/trunk/src/java/org/apache/velocity/util/introspection/UberspectImpl.java
velocity/engine/trunk/src/test/org/apache/velocity/test/ForeachTestCase.java
Modified:
velocity/engine/trunk/src/java/org/apache/velocity/util/introspection/UberspectImpl.java
URL:
http://svn.apache.org/viewvc/velocity/engine/trunk/src/java/org/apache/velocity/util/introspection/UberspectImpl.java?rev=579331r1=579330r2=579331view=diff
==
---
velocity/engine/trunk/src/java/org/apache/velocity/util/introspection/UberspectImpl.java
(original)
+++
velocity/engine/trunk/src/java/org/apache/velocity/util/introspection/UberspectImpl.java
Tue Sep 25 10:59:43 2007
@@ -139,6 +139,22 @@
}
return new EnumerationIterator((Enumeration) obj);
}
+else
+{
+// look for an iterator() method to support the JDK5 Iterable
+// interface or any user tools/DTOs that want to work in
+// foreach without implementing the Collection interface
+Class type = obj.getClass();
+try
+{
+Method iter = type.getMethod(iterator, null);
+return (Iterator)iter.invoke(obj, null);
+}
+catch (NoSuchMethodException nsme)
+{
+// eat this one, but let all other exceptions thru
+}
+}
/* we have no clue what this is */
log.error(Could not determine type of iterator in #foreach loop
at + i);
Modified:
velocity/engine/trunk/src/test/org/apache/velocity/test/ForeachTestCase.java
URL:
http://svn.apache.org/viewvc/velocity/engine/trunk/src/test/org/apache/velocity/test/ForeachTestCase.java?rev=579331r1=579330r2=579331view=diff
==
---
velocity/engine/trunk/src/test/org/apache/velocity/test/ForeachTestCase.java
(original)
+++
velocity/engine/trunk/src/test/org/apache/velocity/test/ForeachTestCase.java
Tue Sep 25 10:59:43 2007
@@ -21,6 +21,7 @@
import java.io.StringWriter;
import java.util.ArrayList;
+import java.util.Iterator;
import java.util.List;
import junit.framework.TestCase;
@@ -75,10 +76,10 @@
}
/**
- * Tests proper method execution during a Foreach loop with items
- * of varying classes.
+ * Tests proper method execution during a Foreach loop over a
Collection
+ * with items of varying classes.
*/
-public void testMethodCall()
+public void testCollectionAndMethodCall()
throws Exception
{
List col = new ArrayList();
@@ -94,4 +95,41 @@
assertEquals(Method calls while looping over varying classes
failed,
int 100 str STRVALUE , writer.toString());
}
+
+/**
+ * Tests that #foreach will be able to retrieve an iterator from
+ * an arbitrary object that happens to have an iterator() method.
+ * (With the side effect of supporting the new Java 5 Iterable
interface)
+ */
+public void testObjectWithIteratorMethod()
+throws Exception
+{
+context.put(iterable, new MyIterable());
+
+StringWriter writer = new StringWriter();
+String template = #foreach ($i in $iterable)$i #end;
+Velocity.evaluate(context, writer, test, template);
+assertEquals(Failed to call iterator() method,
+ 1 2 3 , writer.toString());
+}
+
+
+public static class MyIterable
+{
+private List foo;
+
+public MyIterable()
+{
+foo = new ArrayList();
+foo.add(new Integer(1));
+foo.add(new Long(2));
+foo.add(3);
+}
+
+public Iterator iterator()
+{
+return foo.iterator();
+}
+}
+
}
--
Forio Business Simulations
Will Glass-Husain
[EMAIL PROTECTED]
www.forio.com
Re: svn commit: r579331 - in /velocity/engine/trunk/src: java/org/apache/velocity/util/introspection/UberspectImpl.java test/org/apache/velocity/test/ForeachTestCase.java
On 9/25/07, Will Glass-Husain [EMAIL PROTECTED] wrote:
Wow, Nathan -- you are on a tear. Nice work.
well, i found a little time to work on some of these nagging little things. :)
WILL
On 9/25/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: nbubna
Date: Tue Sep 25 10:59:43 2007
New Revision: 579331
URL: http://svn.apache.org/viewvc?rev=579331view=rev
Log:
support any object with an iterator() method in #foreach (VELOCITY-443)
Modified:
velocity/engine/trunk/src/java/org/apache/velocity/util/introspection/UberspectImpl.java
velocity/engine/trunk/src/test/org/apache/velocity/test/ForeachTestCase.java
Modified:
velocity/engine/trunk/src/java/org/apache/velocity/util/introspection/UberspectImpl.java
URL:
http://svn.apache.org/viewvc/velocity/engine/trunk/src/java/org/apache/velocity/util/introspection/UberspectImpl.java?rev=579331r1=579330r2=579331view=diff
==
---
velocity/engine/trunk/src/java/org/apache/velocity/util/introspection/UberspectImpl.java
(original)
+++
velocity/engine/trunk/src/java/org/apache/velocity/util/introspection/UberspectImpl.java
Tue Sep 25 10:59:43 2007
@@ -139,6 +139,22 @@
}
return new EnumerationIterator((Enumeration) obj);
}
+else
+{
+// look for an iterator() method to support the JDK5 Iterable
+// interface or any user tools/DTOs that want to work in
+// foreach without implementing the Collection interface
+Class type = obj.getClass();
+try
+{
+Method iter = type.getMethod(iterator, null);
+return (Iterator)iter.invoke(obj, null);
+}
+catch (NoSuchMethodException nsme)
+{
+// eat this one, but let all other exceptions thru
+}
+}
/* we have no clue what this is */
log.error(Could not determine type of iterator in #foreach loop
at + i);
Modified:
velocity/engine/trunk/src/test/org/apache/velocity/test/ForeachTestCase.java
URL:
http://svn.apache.org/viewvc/velocity/engine/trunk/src/test/org/apache/velocity/test/ForeachTestCase.java?rev=579331r1=579330r2=579331view=diff
==
---
velocity/engine/trunk/src/test/org/apache/velocity/test/ForeachTestCase.java
(original)
+++
velocity/engine/trunk/src/test/org/apache/velocity/test/ForeachTestCase.java
Tue Sep 25 10:59:43 2007
@@ -21,6 +21,7 @@
import java.io.StringWriter;
import java.util.ArrayList;
+import java.util.Iterator;
import java.util.List;
import junit.framework.TestCase;
@@ -75,10 +76,10 @@
}
/**
- * Tests proper method execution during a Foreach loop with items
- * of varying classes.
+ * Tests proper method execution during a Foreach loop over a
Collection
+ * with items of varying classes.
*/
-public void testMethodCall()
+public void testCollectionAndMethodCall()
throws Exception
{
List col = new ArrayList();
@@ -94,4 +95,41 @@
assertEquals(Method calls while looping over varying classes
failed,
int 100 str STRVALUE , writer.toString());
}
+
+/**
+ * Tests that #foreach will be able to retrieve an iterator from
+ * an arbitrary object that happens to have an iterator() method.
+ * (With the side effect of supporting the new Java 5 Iterable
interface)
+ */
+public void testObjectWithIteratorMethod()
+throws Exception
+{
+context.put(iterable, new MyIterable());
+
+StringWriter writer = new StringWriter();
+String template = #foreach ($i in $iterable)$i #end;
+Velocity.evaluate(context, writer, test, template);
+assertEquals(Failed to call iterator() method,
+ 1 2 3 , writer.toString());
+}
+
+
+public static class MyIterable
+{
+private List foo;
+
+public MyIterable()
+{
+foo = new ArrayList();
+foo.add(new Integer(1));
+foo.add(new Long(2));
+foo.add(3);
+}
+
+public Iterator iterator()
+{
+return foo.iterator();
+}
+}
+
}
--
Forio Business Simulations
Will Glass-Husain
[EMAIL PROTECTED]
www.forio.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VELOCITY-533) Treat arrays like fixed-length lists
[ https://issues.apache.org/jira/browse/VELOCITY-533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Bubna resolved VELOCITY-533. --- Resolution: Fixed Thanks for the contribution Chris. I changed the name to reflect that it isn't just for arrays of primitives. This definitely cleans up and fills out the implementation nicely. Things to note: - When a java.lang.Object method is called on an array in a template, the wrapper is not used. This preserves backwards compatibility - When a length-changing method is called (e.g. add() or remove()), these currently exist but throw UnsupportedOperationExceptions. I'm not sure this is ideal, but i don't think it's wrong. So, i'm leaving it like that. All this is done as of revision 579378 Treat arrays like fixed-length lists Key: VELOCITY-533 URL: https://issues.apache.org/jira/browse/VELOCITY-533 Project: Velocity Issue Type: New Feature Components: Engine Affects Versions: 1.5 Reporter: Nathan Bubna Priority: Minor Fix For: 1.6 Attachments: PrimitiveArrayList.java, PrimitiveArrayWrapper.java I'd like to see arrays treated like fixed-length List objects as much as possible. This means auto-magically supporting size(), set(int,Object), get(int), and isEmpty() at a minimum. Support for something like iterator() probably isn't necessary, since #foreach already handles arrays, but it might be good for completeness. These should be possible via some Uberspect hackery. And since the goal is to free template authors from having to care about the differences between Lists and arrays, we might also consider supporting conversion between the two for method calls, so: $foo.wantsListHere($thisisAnArray) and $bar.wantsArrayHere($thisisAList) both work automatically. I haven't yet looked into what it would take to do this. If it is too hard or messy, i could be happy with just support for calling List methods on arrays. -- 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: svn commit: r579331 - in /velocity/engine/trunk/src: java/org/apache/velocity/util/introspection/UberspectImpl.java test/org/apache/velocity/test/ForeachTestCase.java
what if it returns something you can't iterate over? Maybe check the
return type first?
geir
On Sep 25, 2007, at 4:22 PM, Nathan Bubna wrote:
On 9/25/07, Will Glass-Husain [EMAIL PROTECTED] wrote:
Wow, Nathan -- you are on a tear. Nice work.
well, i found a little time to work on some of these nagging little
things. :)
WILL
On 9/25/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: nbubna
Date: Tue Sep 25 10:59:43 2007
New Revision: 579331
URL: http://svn.apache.org/viewvc?rev=579331view=rev
Log:
support any object with an iterator() method in #foreach
(VELOCITY-443)
Modified:
velocity/engine/trunk/src/java/org/apache/velocity/util/
introspection/UberspectImpl.java
velocity/engine/trunk/src/test/org/apache/velocity/test/
ForeachTestCase.java
Modified:
velocity/engine/trunk/src/java/org/apache/velocity/util/
introspection/UberspectImpl.java
URL:
http://svn.apache.org/viewvc/velocity/engine/trunk/src/java/org/
apache/velocity/util/introspection/UberspectImpl.java?
rev=579331r1=579330r2=579331view=diff
==
---
velocity/engine/trunk/src/java/org/apache/velocity/util/
introspection/UberspectImpl.java
(original)
+++
velocity/engine/trunk/src/java/org/apache/velocity/util/
introspection/UberspectImpl.java
Tue Sep 25 10:59:43 2007
@@ -139,6 +139,22 @@
}
return new EnumerationIterator((Enumeration) obj);
}
+else
+{
+// look for an iterator() method to support the JDK5
Iterable
+// interface or any user tools/DTOs that want to
work in
+// foreach without implementing the Collection
interface
+Class type = obj.getClass();
+try
+{
+Method iter = type.getMethod(iterator, null);
+return (Iterator)iter.invoke(obj, null);
+}
+catch (NoSuchMethodException nsme)
+{
+// eat this one, but let all other exceptions thru
+}
+}
/* we have no clue what this is */
log.error(Could not determine type of iterator in
#foreach loop
at + i);
Modified:
velocity/engine/trunk/src/test/org/apache/velocity/test/
ForeachTestCase.java
URL:
http://svn.apache.org/viewvc/velocity/engine/trunk/src/test/org/
apache/velocity/test/ForeachTestCase.java?
rev=579331r1=579330r2=579331view=diff
==
---
velocity/engine/trunk/src/test/org/apache/velocity/test/
ForeachTestCase.java
(original)
+++
velocity/engine/trunk/src/test/org/apache/velocity/test/
ForeachTestCase.java
Tue Sep 25 10:59:43 2007
@@ -21,6 +21,7 @@
import java.io.StringWriter;
import java.util.ArrayList;
+import java.util.Iterator;
import java.util.List;
import junit.framework.TestCase;
@@ -75,10 +76,10 @@
}
/**
- * Tests proper method execution during a Foreach loop with
items
- * of varying classes.
+ * Tests proper method execution during a Foreach loop over a
Collection
+ * with items of varying classes.
*/
-public void testMethodCall()
+public void testCollectionAndMethodCall()
throws Exception
{
List col = new ArrayList();
@@ -94,4 +95,41 @@
assertEquals(Method calls while looping over varying
classes
failed,
int 100 str STRVALUE , writer.toString());
}
+
+/**
+ * Tests that #foreach will be able to retrieve an iterator
from
+ * an arbitrary object that happens to have an iterator()
method.
+ * (With the side effect of supporting the new Java 5 Iterable
interface)
+ */
+public void testObjectWithIteratorMethod()
+throws Exception
+{
+context.put(iterable, new MyIterable());
+
+StringWriter writer = new StringWriter();
+String template = #foreach ($i in $iterable)$i #end;
+Velocity.evaluate(context, writer, test, template);
+assertEquals(Failed to call iterator() method,
+ 1 2 3 , writer.toString());
+}
+
+
+public static class MyIterable
+{
+private List foo;
+
+public MyIterable()
+{
+foo = new ArrayList();
+foo.add(new Integer(1));
+foo.add(new Long(2));
+foo.add(3);
+}
+
+public Iterator iterator()
+{
+return foo.iterator();
+}
+}
+
}
--
Forio Business Simulations
Will Glass-Husain
[EMAIL PROTECTED]
www.forio.com
-
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]
