commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <tcu...@apache.org>
Subject Re: [javaflow] test cases in junit?
Date Mon, 31 Jan 2005 00:55:09 GMT
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

Mime
View raw message