On Aug 4, 2008, at 01:41, Peter Niederwieser wrote:
Thanks for the quick reply. Just wanted to go sure that excluding
individual
methods is not possible as of now.
No ...not of now
Maybe you'd be interested to hear what
"your" software is used for:
Indeed! :)
I'm developing a workflow engine where
workflows are described in a Scala-based DSL and communicate with
remote
services over JMS. The use of continuations has several benefits:
- Workflows don't block a thread when waiting for messages
- Workflows can be written in a sequential as opposed to CPS style
(cf.
Scala actors)
- Workflows can be persisted to disk so that they survive a system
crash
A (simple) workflow definition currently looks like this:
<snip/>
That looks darn interesting.
Kohsuke did something (remotely) similar with javaflow.
https://dalma.dev.java.net/nonav/maven/index.html
In fact a couple of people mailed me in private about projects like
that.
But I have to say - nothing look so cool like yours ;)
As you can imagine, class Workflow defines many more methods which
can be
used from within a then-block. However, only a few of them (such as
service.book()) need to wait for a response message and therefore
suspend.
Most other methods (such as succeed(), fail(), and all the synthetic
methods
inserted by the Scala compiler) don't. So it would be handy to have
some
control over what methods are (not) instrumented
I see
I recently came across a post of yours where you say that quite a
few things
need to be fixed before a 1.0 release of JavaFlow. Is there a document
(JIRA?)
http://svn.apache.org/repos/asf/commons/sandbox/javaflow/trunk/TODO
describing all known problems and limitations, or could you
(briefly) list them here?
From the TODO:
o fix unintialized objects for method/constructor calls
o inner classes
o try/catch/finally o synchronized(obj)
o accessing .class
o new Object() without assignment
So far my research only revealed that there seems
to be a problem with try-catch-finally.
Unfortunately there is more. But you don't alway hit them :)
In general the question is which way to go. There is the ASM
implementation that is still very basic (and slow as I have been
told). And there is the original BCEL implementation. But BCEL is
really not more than in light maintenance mode. I would rather get rid
of that dependency if possible. But that is a big change.
The testcases also need to be revisited. The current setup is terrible
over-complicated.
So there is quite some work to do. Frankly speaking I got a little
annoyed that so many people use javaflow but never contribute back. So
as I am not using it myself anymore these days - not so motivated to
finish it up. (Although it would be nice to get a release out!)
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
