Re: [javaflow] test cases in junit?
Torsten Curdt wrote: * I added a ContinuationException class that can be thrown to clients using this code instead of stuff like java.lang.reflect.InvocationTargetException that is dependent on the underlying bytecode toolkit. That class was missing in your patch. Besides I am wondering what you mean by dependand on the bytecode toolkit?! There was a note in TODO about investigating using ASM instead of BCEL. Without even looking in detail at ASM, my guess is that it will throw different exceptions than BCEL when manipulating the bytecode, etc. My idea was that we could throw a ContinuationException instead of the underlying FooException that either BCEL or ASM uses to insulate any calling classes from having to change in the event of a switch from BCEL to ASM. Please have a look into the one I've committed. Continueing from the very same continuation is totally ok! Keep the tree of continuations in mind! Ok, thanks for correcting me. * In the TODO file, you mention something about removing the Continuable and ContinuationCapable marker interfaces. Can you please elaborate on the reasons behind that? The Continuable marks classes that should be rewritten. The ContinuationCapable mark classes that have been rewritten. IMO this can all go away. We could define that on a package scope. E.g. via regexp. Going for a decend callflow analyses would even figure out the needed rewrites by itself. Might be some work though... I think I understand the reason why both of these interfaces exist. However, if the intent is to be able to use Continuation.suspend() within any class without having to implement Continuable on that class, then maybe just do away with Continuable and keep ContinuationCapable as the marker for that class after it has been rewritten. What benefit does the regex approach provide? Callflow analyses seems like it could be messy. And I think just tagging the rewritten class with this interface is pretty transparent, no? phil. -- Whirlycott Philip Jacob [EMAIL PROTECTED] http://www.whirlycott.com/phil/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [javaflow] test cases in junit?
* I added a ContinuationException class that can be thrown to clients using this code instead of stuff like java.lang.reflect.InvocationTargetException that is dependent on the underlying bytecode toolkit. That class was missing in your patch. Besides I am wondering what you mean by dependand on the bytecode toolkit?! There was a note in TODO about investigating using ASM instead of BCEL. Without even looking in detail at ASM, my guess is that it will throw different exceptions than BCEL when manipulating the bytecode, etc. My idea was that we could throw a ContinuationException instead of the underlying FooException that either BCEL or ASM uses to insulate any calling classes from having to change in the event of a switch from BCEL to ASM. The java.lang.reflect.InvocationTargetException comes from the use of the reflection API. And maybe it's the only one that we have to catch at that stage anyway. I haven't really made up my mind whether I would like to see an Exception in the suspend() signature. ..but I tend to say we don't need one. If something goes wrong at that stage -and it is not due to reflection- something is heavily broken and throwing a specific exception probably won't help much. ...but I am open to suggestions! The Continuable marks classes that should be rewritten. The ContinuationCapable mark classes that have been rewritten. IMO this can all go away. We could define that on a package scope. E.g. via regexp. Going for a decend callflow analyses would even figure out the needed rewrites by itself. Might be some work though... I think I understand the reason why both of these interfaces exist. However, if the intent is to be able to use Continuation.suspend() within any class without having to implement Continuable on that class, then maybe just do away with Continuable and keep ContinuationCapable as the marker for that class after it has been rewritten. What benefit does the regex approach provide? Callflow analyses seems like it could be messy. IMO a callflow analysis would be the cleanest possible way. ...we would only need to wrap the method calls that actually have an impact on the continuation. Only methods that possibly could call suspend() need to be taken care of. If we had the entry point we should be able to find out whether we need to instrument the class without specifing any additional information. And I think just tagging the rewritten class with this interface is pretty transparent, no? ...it is straight forward for sure. IIRC Stephan introduced ContinuationCapable. Need to check why this was necessary - we were running without beforehand. cheers -- Torsten signature.asc Description: OpenPGP digital signature
Re: [javaflow] test cases in junit?
Ok, here's a start, anyway.
Some notes:
* The simplelog setup wasn't working at all for me for anything less
than info, so I added log4j into the project.xml. Works fine now. Not
sure if you were having a similar problem? junit is also added to
project.xml.
* There are some references to /home/tcurdt in .classpath. I didn't
touch them. Does this even belong in svn?
* I added a ContinuationException class that can be thrown to clients
using this code instead of stuff like
java.lang.reflect.InvocationTargetException that is dependent on the
underlying bytecode toolkit.
* Added some serialVersionUID fields to Serializable classes.
* The test case causes an exception to be thrown and tests for it, so be
aware of that when you see the stacktrace in the output.
* In the TODO file, you mention something about removing the Continuable
and ContinuationCapable marker interfaces. Can you please elaborate on
the reasons behind that?
Just starting off small for now - more soon.
phil.
Torsten Curdt wrote:
Any objections to receiving test cases using junit?
Phil, of course not! :)
...actually it was my plan using junit for that.
cheers
--
Torsten
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Whirlycott
Philip Jacob
[EMAIL PROTECTED]
http://www.whirlycott.com/phil/
Index: C:/Documents and Settings/pjacob/My
Documents/workspace/javaflow/.classpath
===
--- C:/Documents and Settings/pjacob/My Documents/workspace/javaflow/.classpath
(revision 149125)
+++ C:/Documents and Settings/pjacob/My Documents/workspace/javaflow/.classpath
(working copy)
@@ -8,5 +8,7 @@
classpathentry kind=var
path=MAVEN_REPO/commons-logging/jars/commons-logging-api-1.0.4.jar/
classpathentry kind=var
path=MAVEN_REPO/commons-logging/jars/commons-logging-1.0.4.jar/
classpathentry kind=var path=MAVEN_REPO/ant/jars/ant-1.5.3-1.jar/
+ classpathentry kind=var
path=MAVEN_REPO/junit/jars/junit-3.8.1.jar/
+ classpathentry kind=var
path=MAVEN_REPO/log4j/jars/log4j-1.2.8.jar/
classpathentry kind=output path=bin/
/classpath
Index: C:/Documents and Settings/pjacob/My
Documents/workspace/javaflow/project.xml
===
--- C:/Documents and Settings/pjacob/My
Documents/workspace/javaflow/project.xml(revision 149125)
+++ C:/Documents and Settings/pjacob/My
Documents/workspace/javaflow/project.xml(working copy)
@@ -68,6 +68,18 @@
artifactIdant/artifactId
version1.5.3-1/version
/dependency
+
+ dependency
+ groupIdjunit/groupId
+ artifactIdjunit/artifactId
+ version3.8.1/version
+ /dependency
+
+ dependency
+ groupIdlog4j/groupId
+ artifactIdlog4j/artifactId
+ version1.2.8/version
+ /dependency
/dependencies
/project
Index: C:/Documents and Settings/pjacob/My
Documents/workspace/javaflow/src/test/org/apache/commons/javaflow/ContinuationClassLoaderTestCase.java
===
--- C:/Documents and Settings/pjacob/My
Documents/workspace/javaflow/src/test/org/apache/commons/javaflow/ContinuationClassLoaderTestCase.java
(revision 149125)
+++ C:/Documents and Settings/pjacob/My
Documents/workspace/javaflow/src/test/org/apache/commons/javaflow/ContinuationClassLoaderTestCase.java
(working copy)
@@ -18,6 +18,8 @@
import java.lang.reflect.Method;
import java.util.Map;
+import junit.framework.TestCase;
+
import org.apache.commons.javaflow.utils.ReflectionUtils;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
@@ -27,40 +29,70 @@
* @author tcurdt
*
*/
-public final class ContinuationClassLoaderTestCase {
+public final class ContinuationClassLoaderTestCase extends TestCase {
+/**
+ * Logger.
+ */
private final static Log log =
LogFactory.getLog(ContinuationClassLoaderTestCase.class);
-private void testCalculator() throws Exception {
+public void testCalculator() throws Exception {
+log.debug(Doing testCalculator());
+
+final String calculatorTestClass =
org.apache.commons.javaflow.testcode.Calculator;
+
final ClassLoader cl = new
ContinuationClassLoader(getClass().getClassLoader());
-final Class clazz =
cl.loadClass(org.apache.commons.javaflow.testcode.Calculator);
+final Class clazz = cl.loadClass(calculatorTestClass);
+assertNotNull(clazz);
-final Map m = ReflectionUtils.discoverMethods(clazz);
+//This map contains methods indexed by their names (Strings).
+final Map methods = ReflectionUtils.discoverMethods(clazz);
+
Re: [javaflow] test cases in junit?
Phil, thanks for the patch! I did apply some of it ...see the comments inline Some notes: * The simplelog setup wasn't working at all for me for anything less than info, so I added log4j into the project.xml. Works fine now. Not sure if you were having a similar problem? junit is also added to project.xml. I would prefer not add an dependency to log4j. Should be up to the user to provide the prefered logging. Just add -Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog to your jvm startup and it should work fine. * There are some references to /home/tcurdt in .classpath. I didn't touch them. Does this even belong in svn? Yeah, it's the eclipse classpath file. Should be gone now. * I added a ContinuationException class that can be thrown to clients using this code instead of stuff like java.lang.reflect.InvocationTargetException that is dependent on the underlying bytecode toolkit. That class was missing in your patch. Besides I am wondering what you mean by dependand on the bytecode toolkit?! * Added some serialVersionUID fields to Serializable classes. This is only required when you need versioning of serializable classes. We don't need that. * The test case causes an exception to be thrown and tests for it, so be aware of that when you see the stacktrace in the output. I've seen what you were trying in the testcase. But that was not right. Please have a look into the one I've committed. Continueing from the very same continuation is totally ok! Keep the tree of continuations in mind! * In the TODO file, you mention something about removing the Continuable and ContinuationCapable marker interfaces. Can you please elaborate on the reasons behind that? The Continuable marks classes that should be rewritten. The ContinuationCapable mark classes that have been rewritten. IMO this can all go away. We could define that on a package scope. E.g. via regexp. Going for a decend callflow analyses would even figure out the needed rewrites by itself. Might be some work though... Just starting off small for now - more soon. Cool bananas! cheers -- Torsten signature.asc Description: OpenPGP digital signature
[javaflow] test cases in junit?
Torsten - Any objections to receiving test cases using junit? phil. -- Whirlycott Philip Jacob [EMAIL PROTECTED] http://www.whirlycott.com/phil/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [javaflow] test cases in junit?
Any objections to receiving test cases using junit? Phil, of course not! :) ...actually it was my plan using junit for that. cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
